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1.  Purpose  of  Document 


The  purpose  of  this  doeument  is  to  deseribe  the  installation  and  the  operation  of  the  Volume 
Sensor  -  Canadian  Demonstrator  Prototype  (CDP).  The  Volume  Sensor  (VS)  is  a  prototype  fire 
and  smoke  deteetion  and  situational  awareness  system  developed  at  the  U.S.  Naval  Researeh 
Laboratory  (NRL).  The  VS  prototype  has  been  repaekaged  into  a  standalone  unit  with  two 
sensor  heads  for  evaluation  by  the  Canadian  Navy. 

This  doeument  is  broken  into  several  seetions.  The  first  sections  are  intended  to  introduce  the 
CDP  and  set  the  scope  of  this  document.  Next,  the  process  of  installation  of  the  CDP  and  its 
various  components  is  discussed.  The  next  section  describes  how  to  operate  the  Volume  Sensor 
for  real-time  demonstrations  and  also  describes  the  situational  awareness  provided  by  the  system. 
The  remainder  of  the  document  contains  further  details  about  each  of  the  hardware  and  software 
components  that  comprise  the  CDP. 

2.  Introduction 

The  Advanced  Volume  Sensor  (VS)  Project  was  one  element  of  the  Office  of  Naval  Research’s 
(ONR)  Future  Naval  Capabilities  program,  Advanced  Damage  Countermeasures.  This  program 
sought  to  develop  and  demonstrate  improved  damage  control  (DC)  capabilities  to  help  ensure 
that  the  recoverability  performance  goals  for  new  ship  programs,  such  as  the  CVN21  family  of 
ships,  could  be  met  with  the  specified  manning  levels  and  damage  control  systems.  Using  a 
multi-sensory  approach,  the  Naval  Research  Laboratory  (NRL)  is  developing  new  detection 
capabilities  for  DC  in  the  shipboard  environment.  Conventional  surveillance  cameras,  which  are 
currently  being  incorporated  into  new  ship  designs,  provide  the  basis  for  the  VS  project.  Video 
Image  Detection  (VID)  is  a  technology  for  the  remote  detection  of  events  within  the  camera’s 
field  of  view  (FOV)  by  applying  image  analysis,  or  machine  vision,  techniques  to  the  video 
image.  Optical  sensor  systems  sensitive  to  radiation  outside  the  visible  spectrum  and  acoustic 
sensors  have  been  developed  in  combination  with  the  VID  technologies  to  produce  an  overall 
sensor  system  that  is  able  to  provide  a  broad  range  of  situational  awareness  for  the  sensor’s  entire 
field  of  view.  The  use  of  remote  sensing  techniques  removes  the  drawback  of  typical  smoke  and 
fire  detection  systems  that  rely  on  the  diffusion  of  gases,  particles,  or  heat  to  the  detector. 

A  Volume  Sensor  Prototype  (VSP)  was  developed  at  NRL  to  provide  an  affordable,  real-time, 
robust,  and  remote  detection  sensor  system  that  provides  detection  and  classification  of  DC 
conditions  such  as  fire,  explosions,  pipe  ruptures,  and  compartment  flooding.  The  VSP 
generates  alarm  notifications  for  action  by  the  Damage  Control  Assistant  and  other  available 
damage  control  systems  based  on  the  detected  event. 
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3.  Additional  Information 

This  document  focuses  on  the  installation  and  operation  of  the  CDP.  The  details  of  how  the 
system’s  hardware,  software,  and  algorithms  were  designed  and  work  are  not  provided  here. 
Details  on  the  2005  testing  of  the  VSP  on  the  ex-USS  Shadwell  are  available  in  References  1  and 
2,  and  the  references  within.  The  design  and  performance  of  the  VSP  as  a  whole  is  discussed  in 
Reference  3  and  the  references  within.  Further  details  about  the  VS  Long- Wavelength  Video 
Detection  (LWVD)  Component  specifically  are  available  in  References  4-6.  Further  details 
about  the  VS  Spectral-Based  Volume  Sensor  (SBVS)  Component  specifically  are  available  in 
References  6  and  7.  Further  details  regarding  the  VS  ACST  Component  can  be  found  in 
Reference  8.  The  SigniFire  system  is  a  COTS  system  from  axonX  Fike.  Documentation  on  the 
SigniFire  hardware  and  software  can  be  found  in  References  17,18,20. 

4.  System  Description 

This  section  gives  a  brief  overview  of  the  CDP  system.  First,  a  brief  overview  of  the  CDP 
system  as  a  whole  is  given.  Next,  a  description  of  the  CDP  Sensor  Head  and  internal 
components,  as  repackaged  from  the  NRL  VSP,  is  given. 

4,1.  System  Overview 

The  CDP  is  a  single-compartment  configuration  of  the  NRL  VSP.  The  CDP  is  comprised  of  a 
collection  of  hardware  components  and  software  applications.  The  CDP  is  composed  of  the 
following  components: 

•  Sensor  elements  for  data  acquisition 

-  CDP  Sensor  Heads 

-  IP  cameras 

•  Auxiliary  data  acquisition  modules 

-  SBVS  Fieldpoint  Unit 

-  Phantom  power  for  the  audio  microphones 

-  SigniFire  network  video  recorder  and  data  bridge 

•  Communications  equipment 

-  Ethernet  network  switch 

-  Cabling 

•  Operator  computer  for 

-  Data  collection 

-  Data  analysis 

-  Data  fusion 

-  Operator  interaction  and  situational  awareness 
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These  elements  and  the  physical  connections  between  the  elements  are  shown  schematically  in 
Figure  4-1.  Section  5  discusses  the  installation  of  the  CDP. 


Fusion  Machine 


Signifire 


Cat  5e  ethernet  cables 


DB9  serial  cables 


BNC  coaxial  cables 


Signifire  Sensor  Head  #2 


Figure  4-1  -  Volume  Sensor  Demonstrator  Prototype  Components  and  Connections 

4,2,  Canadian  Demonstrator  Prototype  Sensor  Head 

The  CDP  sensor  heads  were  fabricated  by  Vibro-Meter,  Inc.  (VMI),  and  contain  six  individual 
sensor  elements.  Two  video  cameras  are  included,  one  color  CCTV  camera,  and  one  long-pass 
(NIR)  filtered  black  and  white  CCTV  camera.  An  audio  microphone  is  included.  Finally,  three 
of  the  non- imaging  SB  VS  sensor  elements  are  included,  the  mid-IR  (4.3  pm),  the  UV,  and  the 
NIR  (1050  nm)  sensors.  The  visible  (590  &  766  nm)  sensors  of  the  original  SBVS  Component 
Prototype  were  not  included  after  a  cost/benefit  analysis  was  conducted  and  indicated  that  they 
could  be  excluded  with  little  or  no  impact  on  performance  [7].  The  CDP  sensor  head  is  shown  in 
Figure  4-2. 
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Figure  4-2  -  Front  View  of  the  Canadian  Demonstrator 
Prototype  Sensor  Head 

Power  is  provided  to  the  CDP  sensor  head  and  the  outputs  from  the  SB  VS  sensor  elements  in  the 
sensor  head  are  accessed  via  a  screw-terminal  connector  on  the  backplane  of  the  sensor  circuitry 
as  shown  in  Figure  4-3.  The  pinout  of  this  connector  is  provided  in  Table  4-1 .  Three 
4-conductor  cables  are  used  to  connect  the  input  power  to  the  units  and  to  bring  the  sensor 
outputs  outside  the  sensor  head.  One  wire  is  used  for  power  and  the  remaining  two  are  used  to 
carry  the  three  signal  outputs.  The  three  sensor  outputs  are  combined  on  a  single  DB-9 
connector  for  connection  to  the  data  acquisition  electronics.  The  pinout  information  for  this 
connector  is  also  provided  in  Table  4-1. 


Figure  4-3  -  Internal  View  of  the  Canadian  Demonstrator 
Prototype  Sensor  Head 
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Table  4-1  -  Wiring  Connection  Pinout  for  CDP  Sensor  Head 


Connection 

Terminal  Block 
Pin 

Wire  Color  /  Cable 
Number 

cFP  DB-9 
Input  Pin 

IR  Signal 

4 

Red  / 1 

1 

IR  Ground 

10 

Green / 1 

6 

NIR  Signal 

2 

Black  /  1 

3 

NIR  Ground 

10 

White  / 1 

7 

UV  Signal 

7 

Black  /  2 

5 

UV  Ground 

10 

White  /  2 

9 

Power  (+24  VDC) 

8 

Red  or  Black  /  3 

N/A 

Power  Ground 

11 

Green  or  White  /  3 

N/A 

The  output  from  each  video  camera  is  standard,  RS-170  analog  video  which  is  presented  on  a 
75  fl,  BNC  coaxial  connectors  (receptacle).  The  microphone  output  cable  is  terminated  with  a 
mini  XLR  connector.  The  microphone  requires  external  phantom  power  to  operate,  as  discussed 
in  Sections  5.5  and  9. 

5.  System  Installation 

This  section  describes  the  installation  and  initial  setup  of  the  CDP.  Figure  5-1  shows  the 
physical  components  and  connections  of  the  prototype.  These  are: 

•  Sensor  heads  and  IP  cameras  for  data  acquisition 

•  Optical  sensor  remote  data  acquisition  module  (Fieldpoint)  for  digitizing  the 
optical  sensor  outputs 

•  Phantom  power  for  the  audio  microphones 

•  Network  switch  to  provide  a  common  network  interface  to  the  various 
components 

•  SigniFire  IP  camera  interface  computer  to  provide  a  data  bridge  from  the 
SigniFire  cameras  to  the  CDP  Fusion  Machine 

•  CDP  Fusion  Machine  computer  for  processing  the  non-SigniFire  data,  performing 
data  fusion,  displaying  alarms  and  situational  awareness,  recording  sensor  head 
video,  and  providing  the  user  interface  for  system  command  and  control 

•  Cable  pathways 
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Figure  5-1  -  Volume  Sensor  Demonstrator  Prototype  Components  and  Connections 
To  install  the  CDP  system,  the  following  steps  are  required. 

•  Identify  appropriate  locations  for: 

-  CDP  Sensor  Heads 

-  Machine  vision  cameras 

-  Computers 

-  Auxiliary  data  acquisition  elements 

-  Cabling 

•  Mount  sensor  elements 

•  Setup  computers  and  auxiliary  data  acquisition  elements 

•  Connect  cabling 

The  remainder  of  this  section  details  the  installation  of  the  CDP  system.  Section  6  details  the 
proper  procedure  for  powering  up  the  CDP  and  the  subsystem  components. 
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5,1,  Sensor  Location 

Figure  5-1  shows  the  individual  components  and  system  interconnections  (cables)  of  the 
installation  of  the  CDP.  Given  the  standalone  nature  of  the  CDP  design,  it  is  anticipated  that  the 
Fusion  Machine  computer,  ^zgnzFzre  NVR  computer,  the  SB  VS  Fieldpoint  unit,  and  the  network 
switch  would  be  collocated  in  a  small  workstation  such  as  table  positioned  outside  the  test 
compartment  and  isolated  from  where  damage  control  testing  actually  occurs.  The  cable  bundles 
supplied  to  connect  the  sensors  with  the  computers  are  all  50  feet  in  length,  the  nominal  cable 
length  limit  for  the  components  that  output  analog  signals. 

NOTE:  The  system  configuration  of  the  NRL  VSP  in  Reference  2  and  similar  references  was 

implemented  to  be  installed  in  multiple  compartments  with  command  and  control  and 
DC  personnel  to  be  situated  at  remote  locations.  While  the  CDP  was  designed  to 
function  as  a  stand-alone  unit,  none  of  the  installation  flexibility  of  the  NRL  VSP  was 
compromised.  Contact  NRL  to  discuss  the  infrastructure  required  for  a  distributed 
installation.  Investment  in  a  significant  amount  of  hardware  would  be  required. 

The  CDP  sensor  heads  and  SigniFire  IP  cameras  are  expected  to  be  mounted  on  the  walls  of  the 
test  compartment  with  the  provided  camera-style  mounts.  An  example  installation  from  the 
recent  shakedown  testing  of  the  CDP  on  the  ex-USS  Shadwell  [9]  is  shown  in  Ligure  5-2. 


Ligure  5-2  -  Typical  installation  of  a  CDP  Sensor  Suite 

The  location  of  the  sensors  in  the  test  compartment  is  at  the  discretion  of  the  test  director,  but  the 
recommended  locations  for  maximum  coverage  and  effectiveness  are  close  to  the  compartment 
ceiling  on  opposing  walls  or  comers.  Care  should  be  taken  to  maximize  coverage  of  the  test 
compartment  with  overlapping  sensor  fields  of  view.  Smoke  tends  to  rise,  so  the  inclusion  of  the 
ceiling  of  the  compartment  in  the  FOV  should  be  favored  over  that  of  the  floor.  Lighting  and 
compartment  illumination  are  also  important  factors  to  consider.  Diffuse  lighting  such  as 
fluorescent  or  other  covered  illumination  sources  are  recommended  over  bare  halogen  lights. 
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which  generate  a  much  more  intense  and  broad  spectrum  of  radiation,  or  bare  filament-based 
lighting.  As  an  example,  the  sensor  layout  for  the  recent  shakedown  testing  of  the  CDP  on  the 
ex-USS  Shadwell  is  shown  in  Figure  5-3. 

NOTE;  If  un-diffused  halogen  lights  are  installed,  they  should  not  be  positioned  such  that 
they  can  directly  or  indirectly  (reflections)  illuminate  the  sensor  heads  or  cameras. 
The  intense  output  from  these  light  sources  deviate  strongly  from  the  typical  design 
background  radiation  levels  for  Volume  Sensor  components  and  will  cause  the 
Volume  Sensor  to  perform  less  efficiently. 


Figure  5-3  -  Volume  Sensor  Placement  During  CDP  Shakedown  Testing 


5,2,  Sensors 

The  CDP  is  designed  to  operate  with  two  sensor  suite  positions,  each  sensor  suite  position 
comprised  of  a  CDP  sensor  head  and  a  SigniFire  IP  camera.  A  CDP  sensor  head  unit  is  shown 
in  Figure  5-4  with  each  of  the  six  sensor  elements  labeled.  A  third  CDP  sensor  head  has  been 
supplied  as  a  spare  unit.  The  mounts  (Videoalarm  P/N  WM800)  for  the  sensor  head  units  are 
shown  in  Figure  5-5  (a).  Mounting  bolts  are  supplied  with  the  mounts  to  attach  the  CDP  sensor 
head  to  the  mount  via  tapped  holes  on  the  bottom  of  the  CDP  sensor  head.  Bolts  or  other  sturdy 
fasteners  may  be  used  to  attach  the  mounts  to  the  walls. 

NOTE;  Each  CDP  sensor  head  weighs  in  excess  of  12  pounds.  The  Videoalarm  mounts  are 
sized  accordingly.  Any  wall  mount  must  also  be  appropriately  sized. 
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The  SigniFire  IP  camera  is  shown  in  Figure  5-6.  Two  SigniFire  IP  cameras  are  supplied  with 
the  CDP.  Spares  can  be  obtained  from  the  manufacturer,  axonX  Fike.  The  mounts  for  cameras 
are  shown  in  Figure  5-5  (b).  The  mounts  (Videoalarm  P/N  CWPM8)  contain  a  thumb  screw 
which  attaches  to  the  mounting  hole  located  on  the  bottom  of  the  camera  unit.  Screws  or  other 
suitable  fasteners  should  be  used  to  attach  the  camera  mounts  to  the  wall. 


Figure  5-4  -  Sensor  head  unit  with  labeled  sensing  components 


Figure  5-5  -  (a)  Sensor  head  mount,  (b)  SigniFire  IP  Camera  mount 
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Figure  5-6  -  SigniFire  IP  machine  vision  camera 

The  combination  of  a  CDP  sensor  head,  or  white  box,  and  a  SigniFire  IP  camera  is  referred  to  as 
a  Sensor  Suite  (SS).  The  CDP  is  designed  to  process  the  incoming  data  from  two  sensor  suites, 
numbered  SS  #1  and  SS  #2.  Table  5-1  lists  the  serial  numbers  of  the  CDP  sensor  heads  and 
SigniFire  IP  cameras  that  are  associated  with  the  two  sensor  suites,  as  the  CDP  was  configured 
at  the  time  of  delivery.  It  is  important  that  the  sensor  elements  be  connected  to  the  CDP  as 
indicated  in  Table  5-1  in  order  to  preserve  the  as-delivered  calibration  of  the  system.  Sensor 
elements  can  be  replaced  as  necessary,  but  the  processes  described  in  the  later  sections  of  this 
document  must  be  followed  for  proper  calibration. 


Table  5-1  -  Serial  Numbers  for  CDP  Sensor  Suite  Components 


Sensor  Suite 

CDP  Sensor  Head 

SigniFire  IP  Camera 

SS#1 

#001 

#345 

SS  #2 

#002 

#394 

All  of  the  cables  provided  to  connect  the  SS  sensor  components  to  the  CDP  are  COTS  and  are 
readily  available.  Two  pre-assembled  cable  sets  are  provided  with  the  system,  one  for  each 
sensor  system.  Some  spares  are  provided  with  the  CDP,  but  not  assembled  into  cable  sets.  Both 
color  coding  and  numbering  are  used  to  distinguish  the  various  components,  cables,  and  how  to 
connect  them.  The  individual  cables  in  each  cable  set  are  labeled  either  #1  or  #2  to  distinguish 
which  should  be  connected  to  or  from  SS  #1  and  SS  #2,  respectively.  The  connectors  of  cable 
set  #2  that  mate  to  the  sensors  are  shown  in  Figure  5-7.  Each  cable  bundle  has  five  connectors, 
as  labeled  in  the  figure.  Many  of  the  connectors  are  symmetrical,  with  the  exceptions  of  the  data 
cable  for  the  Optical  sensors  (a  standard  DB-9  serial  cable)  and  the  audio  microphone  cables. 

The  cable  bundle  should  be  installed  such  that  the  DB-9  plug  connector  is  available  to  connect  to 
DB-9  socket  connector  located  on  the  CDP  sensor  head. 
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Figure  5-7  -  Cable  set  for  sensor  suite  #2 

DC  power  is  provided  to  each  CDP  sensor  head  by  the  supplied  power  brick. 

NOTE:  DO  NOT  connect  the  sensor  heads  to  their  power  bricks  until  all  data  connections  are 

established  and  the  demonstrator  prototype  is  ready  for  power-on.  The  cameras  may 
be  damaged  if  they  are  connected  or  disconnected  when  the  power  is  connected. 
Always  disconnect  the  power  to  the  sensor  heads  prior  to  connecting  or  disconnecting 
the  BNC  video  cables.  There  are  no  LED  or  other  indicators  on  the  sensor  heads  to 
indicate  when  power  is  connected. 

The  SigniFire  IP  cameras  are  powered  with  the  network  cable  by  the  power-over-ethemet  (PoE) 
capability  provided  by  the  network  switch.  No  other  power  supply  is  necessary  for  the  SigniFire 
IP  camera.  An  LED  located  on  the  front  of  the  camera  lens  indicates  that  the  camera  is  powered 
and  the  current  camera  status. 

A  summary  of  the  color  codes  and  numbering  for  the  sensor  cables  is  provided  in  Table  5-2, 
broken  out  by  sensor  suite.  Several  abbreviations  are  used  in  the  table.  In  the  Destination 
column,  "EM"  refers  to  the  Fusion  Machine  computer,  which  is  discussed  in  more  detail  below. 
As  noted  above,  DO  NOT  connect  the  sensor  heads  to  power  until  all  cables  connections  are 
made. 

At  this  point,  the  cable  bundles  should  be  connected  to  the  sensor  heads  and  SigniFire  IP 
cameras.  A  small  screwdriver  can  be  used  to  tighten  the  connector  screws  of  the  DB-9  cables. 
The  connection  of  the  cable  sets  to  their  respective  destinations  should  be  left  to  the  subsystem 
installations  described  below. 
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NOTE:  The  CDP  sensor  heads  are  prototype  units  and  as  such,  care  should  be  taken  with  the 

handling  of  the  units,  particularly  the  cable  set  that  extends  from  the  rear  of  the  CDP 
sensor  head.  Proper  strain  relief  of  the  cables  to  prevent  damage  to  the  cables  and  the 
internal  components  of  the  CDP  sensor  heads  is  required.  The  connection  of  these 
cables  to  the  internal  components  of  the  CDP  is  shown  in  Figure  4-3  for  reference. 

Table  5-2  -  Numbers  and  color  codes  for  sensor  cables 


SS  #1 

Sensor(s) 

Cable  Type 

Color 

Number 

Destination 

UV,  IR,  NIR 
spectral 

DB-9  serial 

blue 

#1 

Fieldpoint/#! 

LWVD  camera 

BNC  coax 

gray 

#1 

FM/Video  #1 

VID  camera 

BNC  coax 

purple 

#1 

FM/Video  #2 

microphone 

microphone 

white/yellow  stripe 

#1 

Stewart/Input  #1 

power 

DC  plug 

yellow 

#1 

power  brick 

IP  camera  (#345) 

Cat  5e  ethernet 

green 

#1 

network  switch 

SS  #2 

Sensor(s) 

Cable  Type 

Color 

Number 

Destination 

UV,  IR,  NIR 
spectral 

DB-9  serial 

blue 

#2 

Fieldpoint/#2 

LWVD  camera 

BNC  coax 

gray 

#2 

FM/Video  #3 

VID  camera 

BNC  coax 

purple 

#2 

FM/Video  #4 

microphone 

microphone 

white/blue  stripe 

#2 

Stewart/Input  #2 

power 

DC  plug 

yellow 

#2 

power  brick 

IP  camera  (#394) 

Cat  5e  ethernet 

green 

#2 

network  switch 

5.3.  Computers 

Two  computers  are  included  as  part  of  the  CDP.  The  Fusion  Machine  is  responsible  for 
processing  the  data  from  the  optical  sensors,  microphones,  and  sensor  head  video  streams, 
performing  data  fusion,  recording  video,  and  providing  the  human  interface  to  the  demonstrator 
prototype.  The  computer  employed  as  the  Fusion  Machine  is  the  Hewlett-Packard  (HP)  Z400 
computer.  The  SigniFire  IP  cameras  are  controlled  and  interfaced  with  via  the  SigniFire 
Network  Video  Recorder  (NVR). 

The  Fusion  Machine  computer  is  the  primary  core  of  the  CDP.  Figure  5-8  shows  the  backplane 
of  the  Fusion  Machine  computer  with  the  locations  for  the  keyboard,  mouse,  and  graphics  card 
connectors  identified.  The  connectors  for  the  network,  video,  and  audio  subsystems  are  also 
shown.  In  order  to  accommodate  cable  lengths,  the  Fusion  Machine  should  be  located  within  50 
feet  of  the  sensor  heads.  A  keyboard,  mouse,  and  FCD  monitor  are  included,  as  are  power  cables 
for  the  computer  and  monitor.  The  supplied  DisplayPort-to-DVI  adapter  should  be  used  to 
connect  the  graphics  card  on  the  rear  of  the  computer,  as  shown  in  Figure  5-8,  to  the  FCD 
monitor  with  one  of  the  supplied  DVI-to-DVI  cables. 
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At  this  point,  the  color-coded  BNC  coaxial  cables  in  the  cable  bundles  from  sensor  suites  #1  and 
#2  should  be  connected  to  the  Fusion  Machine  computer.  The  labels  "Video  1",  "Video2", 
"Videos",  and  "Video4",  shown  Figure  5-8,  correspond  to  the  Fusion  Machine  destinations  listed 
in  Table  5-2  for  the  sensor  head  LWVD  and  VID  cameras.  For  additional  clarity,  the  labels  "1" 
and  "2"  indicate  the  sensor  suite  number,  while  the  colors  "gray"  for  LWVD  and  "purple"  for 
VID  distinguish  where  each  BNC  coaxial  cable  is  connected. 

NOTE:  The  coaxial  video  cables  supplied  are  constructed  from  RG-59A  cable  and  designed 

for  75  Ohm  termination,  as  is  standard  for  video  applications.  Standard  laboratory 
BNC  cables  are  typically  built  from  RG-58  cable  and  designed  for  50  Ohm 
termination.  The  use  of  50  Ohm  cables  will  degrade  performance  and  should  be 
avoided. 

NOTE:  The  use  of  tools  such  as  pliers  to  make  or  break  the  coaxial  cable  connections  is  not 

recommended  and  should  be  avoided.  Cable  damage  will  result. 

NOTE:  A  fifth,  white  BNC  connector  is  available  on  the  Eusion  Machine  located  near  the 

video  input  connectors.  The  connector  is  taped  off  and  unlabeled.  This  connector  is 
not  used  by  the  CDP  and  no  connection  should  be  made  to  it. 
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Figure  5-8  -  Fusion  Machine  computer  backplane  indicating  connectors  for 
keyboard,  mouse,  monitor,  and  the  network,  video,  and  audio  subsystems 

5,4,  Optical  Subsystem 

The  Optical  Subsystem  (the  SBVS  Component  in  VSP  terminology)  is  responsible  for  the 
acquisition  and  digitization  of  data  from  the  UV,  IR,  and  NIR  optical  sensors.  A  remote  data 
acquisition  module,  termed  the  Fieldpoint  Unit  after  the  core  component,  a  National  Instruments 
Compact  Fieldpoint  controller,  samples  and  digitizes  the  analog  outputs  from  the  optical  sensors 
in  each  CDP  head.  The  Fieldpoint  Unit  is  shown  in  Figure  5-9.  Together,  the  optical  sensors  in 
the  CDP  sensor  head,  the  Fieldpoint  Unit,  and  associated  analysis  software  running  on  the  Fusion 
Machine  computer  comprise  the  SBVS  Component  for  the  CDP.  The  SBVS  component  is 
discussed  in  more  detail  in  Section  7. 

The  Fieldpoint  Unit  is  powered  by  US-standard  120  VAC,  60  Hz  power.  A  standard  three-prong 
power  cable  is  supplied.  The  power  switch  located  directly  beneath  the  power  cable  (as  shown 
in  Figure  5-9  (a),  controls  whether  or  not  the  unit  is  powered  and  an  LED  indicator  is  provided 
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for  verification  that  the  unit  is  powered  on.  A  Category  5e  ethemet  cable  should  be  used  to 
connect  the  Fieldpoint  Unit  to  the  network  switch,  as  discussed  below. 

Three  DB-9  connectors  are  provided  for  connecting  the  DB-9  cables  in  each  of  the  cable  sets,  in 
turn  from  each  CDP  sensor  head.  The  connectors  on  the  Fieldpoint  Unit  are  labeled  #1  and  #2  to 
indicate  the  sensor  suite  number.  The  Fieldpoint  Unit  should  be  powered  off  when  making  or 
breaking  cable  connections.  A  small  screwdriver  can  be  used  to  tighten  the  connector  screws. 

NOTE;  The  CDP,  as  delivered,  is  not  configured  to  make  use  of  the  third  connector  on  the 
Fieldpoint  Unit,  Sensor  Suite  #3,  however  the  unit  is  fully  populated  for  potential 
later  use.  Contact  NRL  to  discuss  the  requirements  involved  to  make  use  of  this 
capability. 


b) 

Figure  5-9  -  Fieldpoint  Unit,  (a)  power  and  network,  (b)  serial  data  connections 

5,5,  Audio  Subsystem 

The  audio  subsystem  of  the  CDP  is  responsible  the  collection  and  processing  of  the  audio  signals 
generated  by  the  microphones  in  the  CDP  sensor  heads.  As  is  typical  for  most  microphones,  the 
microphones  require  external  power  to  function.  This  power  source  is  termed  Phantom  Power  in 
the  audio  industry,  and  a  phantom  power  supply  (Stewart  Audio)  is  included  with  the  CDP.  The 
microphones,  phantom  power  supply,  audio  breakout  cable,  digital  audio  card,  and  analysis 
software  comprise  the  acoustics  (ACST)  sensing  system  of  the  CDP.  The  ACST  system  is 
discussed  in  more  detail  in  Section  9. 

To  physically  connect  the  hardware  components  of  the  ACST  subsystem,  the  following  steps  are 
required. 

The  microphone  cable  from  the  cable  set  from  each  of  the  sensor  heads  should  be  connected  to 
the  appropriate  input  of  the  phantom  power  supply,  as  shown  schematically  in  Figure  5-10.  The 
microphone  connector  with  the  yellow  stripe  from  SS  #1  should  be  connected  to  "Input  #1",  the 
connector  with  the  blue  stripe  from  SS  #2  to  "Input  #2". 

The  audio  card  break-out  cable  should  be  connected  to  the  audio  card  in  the  Fusion  Machine 
computer  via  the  DB-25  connectors,  as  shown  in  Figure  5-8.  Only  two  of  the  microphone 
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connectors  on  the  break-out  cable  are  used  in  the  CDP.  These  are  the  white  connector  labeled  "In 
#1"  and  the  red  connector  labeled  "In  #2".  The  other  connectors  on  the  break-out  cable  have 
been  taped  off  and  are  currently  not  used.  White  In  #I  should  be  connected  to  "Output  #1"  on 
the  phantom  power  supply,  and  red  #2  to  "Output  #2".  The  labels  "Sensor  #1"  and  "Sensor  #2" 
on  the  phantom  supply  indicate  the  correct  signal  pathway.  The  phantom  power  supply  comes 
with  a  DC  power  supply  marked  with  orange  tape.  Once  all  data  cable  coimections  are  made,  the 
Vi-in  male  power  plug,  also  marked  with  orange,  should  be  inserted  into  the  Vi-in  female  plug 
marked  in  orange  on  the  phantom  power  supply.  There  are  no  indicator  lights  on  the  phantom 
power  supply. 

When  all  connections  are  complete,  the  connections  to  the  phantom  power  supply  should 
resemble  those  shown  in  Figure  5-11. 


Figure  5-10  -  Schematic  View  of  the  Audio  Subsystem  Components  and  Connections 
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Figure  5-1 1  -  Connections  to  Phantom  Power  Supply 

NOTE;  The  CDP,  as  delivered,  is  configured  to  only  make  use  of  two  microphone  inputs. 

The  unit  is  populated  to  handle  up  to  four  microphones  total  for  potential  future  use. 
Contact  NRL  to  discuss  the  requirements  involved  to  make  use  of  this  capability. 

5.6,  SigniFire  -  Machine  Vision  Subsystem 

The  machine  vision  subsystem  of  the  CDP  provides  the  interface  to  algorithm  outputs  of  the 
SigniFire  IP  cameras  and  consists  of  the  SigniFire  NVR  computer  (including  a  monitor,  a 
keyboard,  and  a  mouse).  The  machine  vision  algorithms  and  processing  are  performed  in 
hardware  embedded  in  the  camera  itself.  Software  on  the  SigniFire  NVR  computer  serves  as  the 
human  interface  for  the  SigniFire  IP  cameras,  archives  the  video  output  and  alarm  states  from 
the  cameras  in  a  proprietary  format  in  a  circular  buffer,  and  provides  the  interface  between  the 
SigniFire  IP  camera  and  the  data  fusion  algorithms  running  on  the  Fusion  Machine  computer. 

The  setup  of  the  SigniFire  system  is  straightforward.  A  Category  5e  ethemet  cable  should  be 
used  to  connect  the  SigniFire  NVR  computer  to  the  network  switch,  as  discussed  below.  The 
launching  and  operation  of  the  SigniFire  server  software  is  discussed  in  Section  6.2. 

NOTE;  The  SigniFire  IP  cameras  are  provided  with  adjustable  focus  lenses.  The  quality  of 
the  image  for  each  camera  should  be  verified  during  installation.  This  can  be  done 
using  the  SigniFire  NVR  software’s  camera  browser  or  by  connecting  a  service 
monitor  to  the  output  BNC  on  the  back  of  the  camera. 

5.7,  Network  Subsystem 

The  network  subsystem  of  the  CDP  consists  of  the  provided  network  switch,  the  power  supply, 
and  the  associated  Category  5e  Ethernet  cables.  The  components  and  connections  of  the  network 
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subsystem  are  shown  in  Figure  5-12.  The  CDP  is  designed  to  use  a  non-routing,  internal,  (i.e., 
192.168.0.XXX),  ethernet-based  network  for  communications  between  the  various  VS 
components.  Network  capabilities  are  provided  by  the  switch,  which  should  be  located  near  the 
Fusion  Machine. 

The  red-labeled  power  connector  and  power  brick  should  be  used  to  power  the  network  switch. 
The  unbundled,  blue  Category  5e  ethernet  cables  should  be  used  to  connect  the  Fusion  Machine 
computer,  the  SigniFire  computer,  and  the  Fieldpoint  unit  to  the  network  switch,  as  shown  in 
Figure  5-1 .  In  addition,  the  blue  Category  5e  ethernet  cables  in  the  sensor  head  cable  bundles 
should  be  used  to  connect  the  two  SigniFire  cameras  to  the  green-labeled  ports  on  the  ethernet 
switch,  as  shown  in  Figure  5-12. 


power  brick 


Fusion  Machine 
HP  Computer 


Network  Switch 


=  Signifire 
Computer 


Fieldpoint 


Cat  Be  ethernet  cabling 


Signifire 
Camera  #1 


Signifire 
Camera  #2 


Figure  5-12  -  Network  subsystem  components  and  cabling 

NOTE:  The  CDP,  as  delivered,  is  configured  to  run  on  the  non-routing  192.168.0.XXX 

subnet.  If  desired,  it  is  possible  to  reconfigure  the  system  to  run  mostly  on  a  live 
Ethernet  network.  Contact  NRL  to  discuss  the  requirements  involved  to  migrate  to  a 
live  Ethernet  network. 

6.  System  Operation 

This  section  describes  the  proper  procedure  for  powering  up  the  CDP  and  how  to  operate  the 
included  software.  The  first  two  sections  outline  the  proper  procedure  for  powering  on  the 
various  hardware  components,  and  then  how  to  launch  the  software  components  and  the 
graphical  user  interface  (GUI).  A  brief  checklist  of  system  diagnostics  is  reviewed  next  to 
ensure  that  all  subsystems  are  functioning  properly.  The  recommended  method  for  conducting  a 
demonstration  test  with  the  CDP  is  reviewed  next.  Then  the  situational  awareness  provided  by 
VS  on  the  GUI  is  described.  Einally,  the  data  logging  and  video  recording  capabilities  are 
documented. 
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6.1,  Power-on  Procedure 

The  components  of  the  CDP  should  be  powered  up  in  the  following  sequence: 

1 .  The  CDP  sensor  heads  should  be  powered  on  by  connecting  the  CDP  sensor  head 
power  cable  to  the  provided  power  supplies.  The  CDP  sensor  head  power  cables 
and  power  supplies  all  have  yellow  labels. 

2.  The  network  switch  should  be  powered  on.  Power  is  applied  by  connecting  the 
unit’s  power  supply  to  the  switch.  Several  of  the  LEDs  on  the  switch  display  will 
illuminate  to  indicate  proper  operation.  All  power  cables  are  marked  with  red 
labels. 

3.  The  Fieldpoint  Unit  should  be  powered  on.  The  unit  is  powered  by  the  switch  on 
the  exterior.  There  is  a  green  power  LED  to  indicate  a  good  power  supply. 

4.  The  microphone  phantom  power  supply  should  be  powered  on.  The  power 
supply  is  labeled  in  orange. 

5.  The  SigniFire  computer  and  monitor  should  be  powered  on.  Press  the  ON  switch 
on  the  front  panel  to  turn  the  computer  on. 

6.  The  Fusion  Machine  computer  and  monitor  should  be  powered  on.  Press  the  ON 
switch  on  the  front  panel  to  turn  the  computer  on. 

It  may  be  convenient  to  use  a  properly-rated,  multiple-outlet  power  strip  and  possibly  extension 
power  cords  to  supply  power  to  the  CDP  sensor  heads  from  a  common  point  with  a  single 
ON/OFF  switch.  Similarly,  a  properly-rated,  multiple-outlet  power  strip  can  be  used  to  distribute 
power  to  all  of  the  remaining  components. 

NOTE:  The  IR  sensor  supplied  in  the  CDP  sensor  heads  requires  a  minimum  of  60  minutes 

and  preferably  120  minutes  to  thermally  stabilize.  If  the  testing  schedule  does  not 
allow  for  sufficient  warm  up  time  each  day,  it  is  recommended  that  sensor  heads  be 
left  powered  for  the  duration  of  testing.  The  CDP  sensor  heads  should  not  be  left 
powered  indefinitely  as  this  will  limit  the  life  span  of  the  included  cameras. 

6.2,  Software  Launch 

The  launching  of  the  software  components  is  divided  into  three  steps.  First,  the  software 
programs  that  perform  the  analysis  of  sensor  data  which  run  on  the  Fusion  Machine  computer  are 
started.  Second,  the  software  that  provides  the  link  between  the  SigniFire  IP  cameras  and  the 
data  fusion  applications  is  launched  on  the  SigniFire  computer.  Third,  the  software  programs 
that  perform  data  fusion  and  provide  situational  awareness  on  the  Fusion  Machine  are  started.  A 
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two-step  launch  procedure  is  used  on  the  Fusion  Machine  in  order  to  allow  the  operator  an 
opportunity  to  verify  that  all  sensor  systems  are  functioning  properly  before  initiating  the  data 
fusion  processing  and  graphical  user  interface. 

The  following  assumes  that  both  the  Fusion  Machine  and  SigniFire  computers  have  started 
properly.  The  Fusion  Machine  computer  will  automatically  log  the  user  in  and  arrive  at  the 
desktop  on  startup  \  To  launch  the  sensor-component  level  analysis  software,  the  operator 
should  double-click  on  the  desktop  icon  labeled  “Volume  Sensor  Component  Launcher”,  as 
shown  in  Figure  6-1.  The  script  file  represented  by  this  icon  launches  the  following  seven 
applications; 

1.  Optical  (SBVS)  for  SS#1 

2.  Optical  (SBVS)  for  SS#2 

3.  Acoustics  for  SS#1  and  #2 

4.  LWVD  Machine  Vision  for  SS  #1 

5.  LWVD  Machine  Vision  for  SS  #2 

6.  CCTV  recording  for  SS  #1 

7.  CCTV  recording  for  SS  #1 


Double¬ 
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VS_CnC 

VS_GUI 

Figure  6-1  -  Fusion  Machine  desktop  icons  for  sensor  programs 

As  indicated  in  Figure  6-1,  it  is  possible,  but  not  recommended,  to  launch  each  piece  of 
component  analysis  software  with  the  seven  icons  boxed  by  a  dashed  line. 


*  The  implied  user  name  for  this  system  is:  VolumeSensor  and  the  login  password  is:  volumeNRL6100.  In  case  the 
operator  forgets  the  login  password,  the  password  hint  feature  contains  the  same  information.  This  is  one  issue  to  be 
addressed  if  the  system  is  to  be  placed  on  a  live  Ethernet  network. 
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The  second  step  is  to  launch  and  configure  the  applications  on  the  SigniFire  computer  that  are 
necessary  for  the  SigniFire  IP  cameras  to  communicate  with  the  CDP  data  fusion  algorithms. 
The  SigniFire  computer  will  present  a  Windows  login  screen  to  the  operator.  The  operator 
should  select  the  SigniFire  user  to  login  .  Briefly,  to  start  up  the  system  requires  that  two 
applications  be  started.  First  the  SpyderGuard  IP  application  is  launched  using  the  previously 
stored  configuration.  The  configuration  file  (nrl  2  channels .  axf)  is  located  on  the  NVR 
desktop,  as  shown  in  Figure  6-2.  Double-click  on  the  configuration  file  to  launch 
SpyderGuard  IP.  Second,  the  VSCS.Bridge  middleware  application  is  launched  using  the  icon 
on  the  NVR  desktop,  also  shown  in  Figure  6-2.  Once  both  systems  have  started  correctly,  the 
main  screen  of  each  application  will  resemble  those  shown  in  Figure  6-3  and  Figure  6-4. 

NOTE:  It  is  recommended  that  once  set  up  for  a  demonstration  series  that  the  SigniFire  NVR 

not  be  power  cycled.  Once  installed  and  properly  configured,  the  SigniFire  system  is 
designed  for  long  term  operation.  If  the  NVR  and  SigniFire  server  software  have 
been  properly  configured  since  the  last  power  cycle,  system  startup  is  straightforward 
with  no  required  configuration.  If  the  system  has  been  power  cycled,  the  extended 
startup  procedure  described  in  Section  10.2  must  be  followed. 


Figure  6-2  -  SigniFire  application  desktop  icons 


^  This  system  has  no  assigned  login  password.  This  is  one  issue  to  be  addressed  if  the  system  is  to  be  placed  on  a 
live  Ethernet  network. 
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Figure  6-3  -  SpyderGuard  IP,  Server  Tab,  with  Cameras  Loaded 


Figure  6-4  -  VSCS.Bridge,  Cluster  Tab 

6,3,  Data  Fusion  and  UI  Software  Launch 

All  component-level  data  analysis  software  is  now  running.  It  is  now  time  to  start  the  data  fusion 
and  UI  elements  of  the  CDP.  Double-click  on  the  “Volume  Sensor  UI  Launcher”  icon  on  the 
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Fusion  Machine  desktop,  as  shown  in  Figure  6-5.  The  script  file  represented  by  this  icon 
launches  the  following  three  applications: 

1.  VS  CnC 

2.  VS  GUI 

3.  VS  Quad 

The  VS  CnC  application  is  the  core  of  the  CDP  Fusion  Machine.  Data  flow  to  the  VS  CnC 
from  the  individual  component-level  analysis  applications,  where  they  are  stored.  The  system- 
wide  data  fusion,  event  detection,  and  situational  awareness  classification  algorithms  are  housed 
in  the  VS  CnC  application  as  well.  State  control  for  the  sensor  components  is  controlled  by  the 
VS  CnC.  Further  details  on  the  VS  CnC  application  can  be  found  in  Section  12.  The  VS  GUI 
is  the  user  interface  where  analysis  results  and  situational  awareness  are  presented  to  the 
operator.  The  operator  uses  the  VS  GUI  application  to  control  the  operation  of  the  CDP. 

Further  details  on  the  VS  GUI  application  can  be  found  in  Section  13.  The  VS  Quad 
application  provides  an  aggregated  view  of  the  camera  output  images  from  the  cameras  in  the 
CDP  sensor  heads.  This  is  provided  to  the  operator  for  enhanced  situational  awareness.  Further 
details  on  the  VS  Quad  application  can  be  found  in  Section  1 1.  A  typical  configuration  of  the 
operator  screen  for  the  CDP  is  shown  in  Figure  6-6.  As  indicated  in  Figure  6-5,  it  is  possible,  but 
not  recommended,  to  launch  each  piece  of  data  fusion  and  UI  software  individually  with  the 
three  icons  boxed  by  a  dashed  line. 
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Figure  6-5  -  Fusion  Machine  desktop  icons  for  GUI  and  data 
fusion  programs 
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Figure  6-6  -  Fusion  Machine  desktop,  configured  for  CDP  operation 

6.4,  Component  System  Verification  Testing 

With  all  of  the  CDP  software  and  hardware  running,  it  is  prudent  for  the  operator  to  ensure  that 
all  of  the  sensor  component  subsystems  are  operating  nominally.  A  brief  set  of  system  checks  is 
outlined  below.  Review  of  Sections  7-10  and  the  references  within  will  provide  further  insight 
into  the  workings  of  each  component  system.  These  tests  are  best  done  with  the  individual 
components  collecting  data  normally,  such  that  all  algorithms  are  functioning  properly.  To  run 
the  tests,  the  operator  should  start  the  system,  as  described  in  Section  6.5  and  allow  the  system 
several  minutes  to  establish  a  good  background. 

For  the  Acoustics  subsystem  (ACST),  a  simple  check  that  the  system  is  functioning  is  to  make  a 
loud  sound,  e.g.  clapping  one’s  hands.  In  Figure  6-7,  the  ACST  application  is  shown  running 
un-minimized.  The  response  to  hand  clapping  by  the  operator,  a  30  dB  amplitude  increase,  is 
highlighted  in  yellow. 

For  the  Optical  subsystem  (SBVS),  a  good  check  is  to  hold  a  long-handled  butane  lighter  in  front 
of  each  sensor  head  and  watch  for  both  changes  in  all  three  signal  levels  (10500A,  ReflRl,  and 
UV_Count)  as  well  as  the  EVENT  and  EIRE_FOV  EVENT  indications.  The  SBVSLogger 
application  running  normally  is  shown  in  Eigure  6-8.  The  same  screen  is  shown  in  Figure  6-9 
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while  a  butane  lighter  is  being  held  in  front  of  the  CDP  sensor  head.  The  outputs  of  interest  are 
highlighted  in  red. 


Figure  6-7  -  ACST  Subsystem  Showing  an  Acoustic  Event  (Clapping  of  Hands) 


Figure  6-8  -  SBVSLogger  main  screen,  system  processing  incoming  data 
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Figure  6-9  -  SBVSLogger  main  screen,  system  detecting  a  FIRE  FOV  EVENT 

For  both  cameras  in  the  CDP  sensor  head,  there  are  two  checks  to  perform.  First,  using  the 
VS  Quad  application,  the  image  quality  from  each  camera  should  be  checked  for  picture  quality. 
The  LWVD  camera  image  will  be  black  and  white,  as  is  the  camera,  and  mostly  dark  due  to  the 
longpass  filter.  The  test  lamp  described  in  Section  7.6  or  other  light  source  (e.g.  a  flashlight)  can 
be  used  to  raise  the  image  intensity  for  inspection.  The  CCTV  cameras  are  color  and  unfiltered, 
so  the  image  is  readily  inspected.  A  good  example  is  shown  in  Figure  6-10.  The  second  check  is 
to  ensure  that  the  cameras  are  working  and  that  the  image  displayed  is  live.  Moving  an  object 
such  as  the  test  lamp  in  the  view  will  verify  this,  as  shown  in  Figure  6-11.  This  test  should  be 
used  to  verify  operation  of  all  instances  of  the  LWVD  application,  both  LWVD  instances 
(LWVD  1  and  LWVD  2)  and  both  DVR  instances  (DVR  1  and  DVR  2). 

To  further  verify  the  operation  of  the  Long-Wavelength  Video  Detection  (LWVD)  component 
subsystem,  a  test  lamp  such  as  the  one  described  in  Section  7.6  is  used.  The  LWVD  application 
is  shown  running  in  a  normal  state  in  Ligure  6-12.  The  test  lamp  should  be  placed  approximately 
5  meters  in  front  of  each  CDP  sensor  head,  aimed  directly  at  the  sensor  head  and  activated.  As 
the  persistence  criteria  in  the  LWVD’s  algorithm  process  the  incoming  data,  the  system  state  will 
change  from  normal  to  pre-alarm,  as  seen  in  Figure  6-13,  and  finally  to  alarm,  as  seen  in  Figure 
6-14. 


The  SigniFire  IP  camera  status  and  functionality  is  best  checked  using  the  SpyderGuard  IP 
software  on  the  SigniFire  computer.  The  test  lamp  should  be  placed  approximately  5  meters  in 
front  of  each  SigniFire  IP  camera,  aimed  directly  at  the  camera  and  activated.  The  FLAME 
detection  algorithm  running  in  the  SigniFire  IP  camera  will  change  state  from  normal,  as  seen  in 
Figure  6-15,  to  alarm,  as  seen  in  Figure  6-16.  The  detection  is  indicated  in  the  SpyderGuard  IP 
browser  window  as  a  red  box. 
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VS-QUAD  -  Canadian  Demonstrator  Prototype 

LvwiX  / 


LWVD 


Figure  6-10  -  Camera  Image  Quality  Verification  using  VS  Quad  Application 


Figure  6-1 1  -  Camera  Status  Verification  using  VS  Quad  Application 
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Figure  6-12  -  LWVD  main  screen,  system  processing  incoming  data 
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Figure  6-13  -  LWVD  main  screen,  system  in  FLAME  pre-alarm  state 

NOTE;  Individual  subsystems  of  the  CDP  use  similar,  but  not  identical  nomenclatures.  For 
example,  the  GUI  FLAME  event  is  referred  to  as  FIRE  by  the  LWVD  subsystem  as 
seen  in  Figure  6-13.  The  GUI  nomenclature  will  be  used  in  this  section  for 
consistency. 
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Figure  6-14  -  LWVD  main  screen,  system  in  a  FLAME  alarm  state 
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Figure  6-15  -  SpyderGuard  IP  Camera  Browser  screen,  system  in  a  normal  state 


Figure  6-16  -  SpyderGuard  IP  Camera  Browser  screen,  system  in  a  FLAME  alarm  state 

If  all  of  these  systems  checks  are  positive,  the  CDP  sensor  subsystem  components  are  operating 
nominally.  At  this  point,  the  operator  should  stop  the  system  and  reset  for  actual  demonstration 
testing. 
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6,5,  Demonstration  Procedures 

This  section  briefly  outlines  the  procedure  for  running  a  single  test  event  as  part  of  a  test  series. 
With  all  component-level  software,  data  fusion,  and  UI  elements  properly  up  and  running,  the 
operator  console  for  the  CDP  should  closely  resemble  the  scene  shown  in  Figure  6-17.  The 
procedures  discussed  in  this  Section  briefly  cover  operator  interaction  with  the  VS  GUI 
application.  For  additional  information  about  using  the  VS  GUI  application,  refer  to  Section  13. 

When  first  started,  the  VS  GUI  application  is  dormant  and  not  communicating  with  the  VS  CnC 
or  any  CDP  subsystems.  To  initialize  communications,  the  operator  presses  the  “I”  button  on  the 
application  menu  bar.  The  button  is  shown  highlighted  red  in  Figure  6-18.  The  initialization 
routine  queries  all  devices  in  the  CDP  and  updates  the  GUI  as  responses  are  received.  A  typical 
VS  GUI  display  after  initialization  is  shown  in  Figure  6-19.  To  start  the  CDP  data  collection 
cycle,  the  operation  presses  the  green  circle  that  is  now  illuminated  on  the  application  menu  bar, 
red  highlighted  in  Figure  6-20.  Once  the  system  is  started  and  data  are  being  received  by  the 
VS  CnC,  the  VS  GUI  display  will  be  similar  to  the  one  shown  in  Figure  6-21.  The  CDP  will 
continue  to  collect  and  analyze  data  until  the  operator  stops  data  acquisition.  Algorithm  results 
and  situational  awareness  cues  will  be  provided  to  the  operator.  Examples  are  shown  in  the  next 
section  of  the  document.  To  stop  data  acquisition,  the  operator  presses  the  red  circle  that  is 
illuminated  on  the  application  menu  bar,  as  shown  highlighted  red  in  Figure  6-22.  The  CDP  is 
now  in  the  idle  state  and  ready  for  the  next  demonstration  test. 

NOTE:  The  VS  CnC  and  VS  GUI  software  have  been  tested  extensively,  but  are  at  the  core, 

research  tools.  If  unexpected  behavior  is  experienced,  restarting  the  VSGUI  and 
possibly  the  VS  CnC  application  is  recommended. 
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Figure  6-17  -  CDP  operator  view  after  a  elean  system  startup 


Figure  6-18  -  Main  VS  GUI  Interfaee  Controls  -  Pre-Initialization 
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Figure  6-19  -  CDP  operator  view  after  Initialization 


Figure  6-20  -  Main  VS  GUI  Interface  Controls  -  Ready  to  Start 
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Figure  6-21  -  CDP  operator  view  with  CDP  colleeting  data 


Figure  6-22  -  Main  VS  GUI  Interfaee  Controls  -  Running 

6,6,  Situational  Awareness 


The  stated  goal  of  the  CDP  system  is  to  deteet  potential  damage  eontrol  events  oeeurring  in  a 
eompartment  in  a  shipboard  environment,  elassify  them  based  on  their  hazard  eharaeteristies, 
rejeet  known  nuisanee  events,  and  present  the  operator  and  other  damage  eontrol  systems  with 
the  results  leading  to  enhanced  situation  awareness.  In  this  section  of  the  document,  the  types  of 
situational  awareness  that  can  be  provided  by  the  CDP  and  the  mechanisms  by  which  they  are 
presented  to  the  operator  are  discussed  and  two  examples  are  shown. 

The  Volume  Sensor  Prototype,  on  which  the  CDP  is  based,  is  designed  to  detect  flame  and 
smoke  events.  Detection  of  smoke  comes  exclusively  from  the  SigniFire  system.  Flame 
detection  capabilities  are  provided  by  the  SigniFire,  LWVD,  and  SBVS  components.  The  data 
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fusion  algorithms  running  on  the  Fusion  Machine  computer  weight  these  systems  differently 
based  on  their  demonstrated,  past  performance.  Further  details  on  this  subject  can  be  found  in 
Reference  3  and  the  references  within.  As  an  example,  the  LWVD  subsystem  FLAME  algorithm 
has  been  found  to  generate  too  many  false  positive  responses  to  be  allowed  to  generate  a 
FLAME  EVENT  on  its  own.  Corroboration  from  another  subsystem  is  required.  As  an 
example,  in  Figure  6-23,  the  LWVD  component  for  both  CPD  sensor  heads  is  indicating  a 
FLAME  pre-alarm  condition  (see  red-highlighted  section).  The  overall  system  status  is  nominal 
(all  green  indications).  As  the  event  continues  to  evolve,  the  LWVD  subsystem  reaches  a 
FLAME  alarm  condition,  as  shown  in  Eigure  6-24  (red-highlighted  section).  The  overall  system 
status  remains  nominal  (all  green  indications)  as  the  data  fusion  algorithms  will  not  declare  a 
FLAME  event  based  on  the  LWVD  subsystem  alone.  As  the  event  continues,  the  SBVS  and 
LWVD  now  both  indicate  a  FLAME  alarm  condition,  as  indicated  by  the  red  highlighted 
sections  in  Figure  6-25.  The  data  fusion  algorithms  now  determine  that  the  FLAME  event  is  real 
and  declare  a  system  wide  ELAME  alarm  condition,  as  indicated  in  the  purple-highlighted 
sections  of  Eigure  6-25. 


Figure  6-23  -  VS  GUI  indicating  an  LWVD-based  FLAME  pre-alarm  condition 
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Figure  6-24  -  VS  GUI  indicating  an  LWVD-based  FLAME  alarm  condition 
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Figure  6-25  -  VS  Data  Fusion  Algorithms  declaring  a  FLAME  event  based  on  the  LWVD  and 
SB  VS  subsystems 

NOTE;  In  Eigure  6-24,  the  LWVD  FLAME  alarm  condition  was  indicated  by  both  SS  #1  and 
#2,  as  indicated  by  the  red  illumination  of  the  “All”,  “1”,  and  “2”  boxes  at  the  top  of  the  red- 
highlighted  area.  In  Figure  6-25,  the  fire  source  had  evolved  such  that  the  SBVS  and  LWVD 
subsystems  in  SS  #1  indicated  a  FLAME  alarm  condition  (indicated  by  the  red  illumination)  but 
SS  #2  has  returned  to  nominal  status  (indicated  by  the  green  illumination). 


The  Volume  Sensor  Prototype  data  fusion  algorithms  are  also  designed  to  detect  several  nominal 
shipboard  conditions  and  bring  them  to  the  operator’s  attention  for  enhanced  situational 
awareness.  The  majority  of  these  conditions  are  driven  by  the  acoustics  subsystem. 

The  ACST  subsystem  monitors  the  ambient  noise  in  the  test  compartment  and  when  sounds 
typical  of  an  event,  such  as  water  falling,  are  detected,  it  reports  a  WATER  or  other  event  based 
on  the  noise  detected.  This  is  done  through  two  types  of  data  passed  to  the  Fusion  Machine, 
channel  data  and  alarm  status  for  each  event.  The  channel  data  represents  an  estimate  of  the 
probability  of  an  event.  As  an  event  persists,  the  alarm  level  is  continually  raised  until  it  is 
considered  fully  set  and  an  event  is  formally  considered  detected.  Table  6-1  lists  the  different 
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types  of  events  looked  for  by  the  acoustie  proeessing  software.  The  abbreviation  column  is  used 
in  real-time  monitoring  of  the  processing  in  a  terminal  window,  see  Figure  6-7. 

Table  6-1  -  Audio  Events  and  Alarms 


Event 

Abbreviation 

Alarm  Type 

Sensor  Overload 

0 

Event 

Background  Noise 

N 

Background 

Water 

W 

Pipe  Rupture 

Mist 

M 

Event 

Gas  Leak 

G 

Event 

Torch 

T 

Nuisance 

Grinding 

R 

Nuisance 

Welding 

L 

Nuisance 

Engine 

E 

Nuisance 

People 

P 

Nuisance 

Activity 

H 

Nuisance 

The  Water  and  Gas  Leak  ACST  events  are  treated  as  damage  control  events  and  annunciated  to 
the  operator  in  the  same  manner  and  screen  locations  as  FLAME  and  SMOKE.  The  remaining 
events  are  annunciated  as  nuisance  events.  Nuisance  events  are  presented  to  the  operator  for 
general  situational  awareness  and  also  as  a  reminder  of  the  CDP  operating  status.  These  events 
are  annunciated  in  the  Nuisance  Data  Table  section  of  the  VS_GET  screen,  as  shown  in  Figure 
6-26.  For  example,  the  SBVS  subsystem  generates  one  positive  nuisance  event  condition,  the 
presence  of  arc  welding.  If  the  SBVS  subsystem  reports  the  presence  of  an  arc  welding  nuisance 
in  the  compartment,  all  data  fusion  alarm  conditions  {i.e.  FLAME  and  SMOKE)  for  the 
compartment  are  blocked  from  activating  until  one  minute  after  the  WELDING  event  has 
cleared.  The  indication  of  the  WELDING  nuisance  on  the  VS  GUI  display  warns  the  operator 
that  FLAME  alarms  are  currently  blocked.  An  example  of  a  pre-alarm  condition  for  the 
PEOPLE  event  is  shown  in  Figure  6-27. 
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Figure  6-26  -  VS_GUI  Nuisance  Data  Table 
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Figure  6-27  -  VS_GUI  Nuisance  Data  Table  indicating  People  in  the  Space 

The  discussion  in  this  section  gives  a  brief  introduction  to  the  rich  set  of  information  and 
situational  awareness  provided  by  VSP  systems  such  as  the  CDP.  For  further  discussion,  refer  to 
Section  13. 

6,7,  Data  Output 

Most  of  the  CDP  data  files  are  stored  on  the  Fusion  Machine  computer’s  data  drive  (f:  \)  in 
directories  by  component.  The  data  fusion  data  files  are  stored  on  the  computer’s  main  drive  and 
should  be  archived  after  each  demonstration  test.  A  pair  of  desktop  shortcuts  has  been  set  up  to 
facilitate  data  backups,  as  shown  in  Figure  6-28.  The  data  fusion  data  files  to  be  archived  from 
the  main  drive  (c :  \  )  are; 
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•  DFAM_Log . txt 

•  dataSSl_Log.txt,  dataSS2_Log.txt 

•  dataDFl_Log.txt 

•  CnC_Logf ile_MM-DD_YY _ HH-MM-SS . txt 

These  files  are  located  in  the  VS-CnC  application  directory, 

"C:\Volume  Sensor  Programs\VS-CnC" 


Desktop  shortcuts  to  data 

archive  locations 

1  ^ 

_ 

1  Datastorage 

VS-CNC  1  CDP  Data  Shortcut  to 

I.  _  _ 

— 

1  Volume  Sen... 

Figure  6-28  -  Desktop  Shortcuts  for  Data  Archiving 

The  SBVS  and  LWVD  data  files  are  individually  time-stamped  as  described  in  Sections  7.3  and 
8.2.3.  It  is  recommended  that  the  SBVS,  LWVD,  and  DVR  data  files  be  archived  at  the  end  of 
each  day  into  test-specific  directories.  The  data  directories  can  be  reached  quickly  by  double¬ 
clicking  the  “Datastorage  (F)  ”  desktop  shortcut.  The  SBVS  data  files  are  stored  in  the 
directory: 

"F:\SBVS  Data  Files\" 

The  LWVD  application  generates  several  types  of  data  files,  as  described  in  Section  8.2.3, 
including  archival  video  files.  In  DVR  mode,  the  LWVD  application  only  records  archival  video 
files.  The  LWVD  and  DVR  data  files  are  stored  in  the  directory: 

"F:\LWVD  Data  Files\" 

The  ACST  subsystem  does  not  store  data  locally  under  normal  operating  conditions.  See  Section 
9.4  for  further  details  on  the  ACST  subsystem  testing  mode  which  does  enable  local  data  storage. 
Any  saved  files  for  the  ACST  subsystem  are  stored  in  the  directory: 

"F:\ACST  Data  Files\" 

6,8,  System  Shutdown 

System  shutdown  procedures  are  divided  into  two  categories:  routine,  daily  shutdown  for  during 
a  test  series  and  complete  shutdown  for  disassembly  and  storage. 
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During  a  running  test  series,  the  following  software  applications  should  be  secured  at  the  end  of 
each  work  day  in  the  order  listed; 

1.  VS  GUI 

2.  VS  Quad 

3.  VS  CnC 

4.  SB  VS  (Optical  sensors)  for  SS#1 

5.  SB  VS  (Optical  sensors)  for  SS#2 

6.  ACST  (Acoustics)  for  SS#1  and  #2 

7.  LWVD  Machine  Vision  for  SS  #1 

8.  LWVD  Machine  Vision  for  SS  #2 

9.  DVR  (CCTV  recording)  for  SS  #1 

10.  DVR  (CCTV  recording)  for  SS  #1 

Prior  to  securing  any  software,  the  operator  should  insure  that  all  systems  have  stopped  recording 
data.  Each  software  package  is  closed  using  one  of  the  standard  Windows  paradigms.  The 
LWVD,  DVR,  and  VS  CnC  applications  have  a  “Done”  button  on  the  main  GUI.  Pressing  this 
button  closes  the  application.  The  VS_GUI  and  SBVS  applications  are  closed  by  selecting  the 
menu  choice  “File/Exit”.  The  VS  Quad  application  is  closed  by  pressing  the  “x”  in  the  upper- 
righthand  comer  of  the  application  window.  The  ACST  application  is  closed  by  pressing  the  “q” 
button. 

The  applications  mnning  on  the  SigniFire  computer  should  be  left  mnning. 

For  routine,  daily  hardware  shutdown,  the  Fusion  Machine  computer,  the  phantom  power  supply, 
and  Fieldpoint  Unit  should  now  be  turned  off  The  CDP  sensor  heads  should  be  left  powered 
overnight  unless  the  recommended  120  minute  warm  up  time  is  available  each  day. 

If  the  system  is  to  be  powered  down  for  an  extended  period,  the  two  applications  mnning  on  the 
SigniFire  computer  should  be  shut  down.  The  SigniFire  computer  should  be  shutdown.  Finally, 
the  network  switch  and  CDP  sensor  heads  should  be  turned  off.  To  protect  against  power 
conditioning  issues,  all  power  cords  and  plug  strips  should  be  disconnected  from  their  supply 
outlets. 

7.  Spectral-Based  Volume  Sensor  (SBVS)  Component 

Routine  operation  of  the  SBVS  component  for  the  CDP  is  straightforward  and  requires  no 
operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is  required 
and  is  presented  in  this  Section.  The  information  in  this  Section  is  excerpted  for  Reference  10. 
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lA.  SBVS  Data  Acquisition  Electronics 

Data  acquisition  (the  conversion  of  analog  signals  to  digital  information)  is  performed  in  the 
SBVS  Fieldpoint  Unit.  The  Fieldpoint  Unit  is  shown  in  Figure  7-1 . 


Figure  7-1  -  SBVS  Fieldpoint  Unit 
An  interior  view  of  the  Fieldpoint  Unit  is  shown  in  Figure  7-2. 


Figure  7-2  -  Interior  View  of  SBVS  Fieldpoint  Unit 

At  the  heart  of  the  Fieldpoint  Unit  is  a  National  Instruments  compact  Fieldpoint  (cFP)  distributed 
data  acquisition  system  (cFP-2000).  Standard  9-pin  serial  cables  are  used  to  connect  the  SBVS 
sensors  in  the  CDP  sensor  heads  to  the  data  acquisition  electronics  at  distances  of  up  to  50  feet. 
The  electrical  connections  from  the  CDP  sensor  heads  to  the  Fieldpoint  Unit  to  the  data 
processing  PC  are  shown  in  Figure  7-3.  Analog  signals  are  shown  as  solid  lines  and  digital 
(network)  connections  are  shown  as  dashed  lines. 
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Figure  7-3  -  Schematic  Wiring  Diagram  for  the  SBVS  Component 

The  Fieldpoint  Unit,  as  configured,  is  capable  of  operating  three  CDP  sensor  heads  at  one  time. 
However,  the  planned  configuration  of  the  CDP  as  a  whole  will  only  support  the  operation  of 
two  sensor  heads  at  a  time.  The  Fieldpoint  Unit  contains  a  network  control  module  (cFP-2000), 
an  analog  input  (AI)  module  (cFP-AI-1 10),  and  a  digital  counter  module  (cFP-CTR-502).  The 
cFP-2000  module  handles  the  data  acquisition  and  communication  with  the  data  processing  PC. 
The  AI  module  has  8  single-ended  inputs.  Each  input  is  configured  for  a  0-10.4  VDC  input 
range  to  match  the  outputs  of  the  sensors  and  a  60  Hz  line  filter  is  applied.  The  inputs  are  used 
in  pairs,  one  for  the  IR  sensor  and  one  for  the  NIR  sensor  for  a  given  CDP  sensor  head.  Three 
pairs  (6  total)  are  wired  to  the  front  panel  for  connection  to  CDP  sensor  heads.  Wire  connections 
to  the  AI  module  are  made  using  a  cFP-CB-1  terminal  block.  The  remaining  two  pairs  are  dead- 
shorted  to  prevent  baseline  drift.  The  connection  information  for  the  analog  inputs  is  listed  in 
Table  7-1. 


Test  Compartment 
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Table  7-1  -  Wiring  Connection  Pinout  for  SBVS  Fieldpoint  Analog  Inputs 


Connection 

Terminal 

Block  Pin 

Wire  Color 

cFP  DB-9  #  / 
Input  Pin 

IR  Signal  1 

1 

Red 

1  /  1 

IR  Ground  1 

18 

Green 

1/6 

NIR  Signal  1 

3 

Black 

1/3 

NIR  Ground  1 

20 

White 

1/7 

IR  Signal  2 

5 

Red 

2/1 

IR  Ground  2 

22 

Green 

2/6 

NIR  Signal  2 

7 

Black 

2/3 

NIR  Ground  2 

24 

White 

2/7 

IR  Signal  3 

9 

Red 

3/1 

IR  Ground  3 

26 

Green 

3/6 

NIR  Signal  3 

11 

Black 

3/3 

NIR  Ground  3 

28 

White 

3/7 

The  UV  sensor  output  is  a  series  of  pulses  rather  than  a  continuous  voltage  level.  A  digital 
counter  (CTR)  (cFP-CTR-502)  is  used  to  count  the  number  of  pulses  in  a  given  time  period, 
typically  one  second.  The  counter  is  designed  to  count  pulses  of  arbitrary  voltages  for  eight 
input  channels,  so  an  appropriate  reference  voltage  is  also  required.  A  +5  VDC  reference 
voltage  is  provided  by  a  power  supply  in  the  Fieldpoint  Unit  and  wired  to  the  CTR  module 
separately.  +5  VDC  is  used  to  match  the  amplitude  of  the  pulse  train  from  the  UV  sensor  and  the 
CTR  input  bandwidth  is  set  to  50  kHz  to  match  the  pulse  width.  Wire  connections  to  the  CTR 
module  are  made  using  a  cFP-CB-1  terminal  block.  The  connection  information  for  the  digital 
inputs  is  listed  in  Table  7-2. 

Table  7-2  -  Wiring  Connection  Pinout  for  SBVS  Fieldpoint  Digital  Inputs 


Connection 

Terminal 
Block  Pin 

Wire  Color 

cFP  DB-9  #  / 
Input  Pin 

UV  Signal  1 

1 

Black 

1/5 

UV  Ground  1 

18 

White 

1/9 

UV  Signal  2 

2 

Black 

2/5 

UV  Ground  2 

20 

White 

2/9 

UV  Signal  3 

3 

Black 

3/5 

UV  Ground  3 

22 

White 

3/9 

+5  VDC  Ref 

V 

Red  and  Black 

N/A 

Ref  Gnd 

c 

Green  and  White 

N/A 

7.2.  SBVSLogger  Software 

The  SBVSLogger  application  is  designed  to  communicate  with  the  SBVS  Fieldpoint  Unit  to 
collect  the  sensor  data,  process  the  data  using  the  VS  SBVS  Component  Prototype  algorithms, 
and  pass  the  sensor  data  and  algorithm  results  to  the  VS  Data  Fusion  Algorithm  via  the  VS  CnC 
application.  While  the  SBVSLogger  software  has  a  full  user  interface  (GUI),  it  is  designed  to  be 
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run  in  an  unattended  mode  onee  configured.  The  configuration  and  operation  of  the  software  is 
briefly  described  here. 

Upon  startup,  the  main  screen  of  the  SBVS  application  is  displayed,  as  shown  in  Figure  7-4.  The 
SB  VS  sensors  in  each  CDP  sensor  head  are  monitored  collectively  by  an  instance  of  the 
SBVSLogger  application.  The  title  bar  of  the  application  notes  which  instance  is  being 
monitored  and  the  network  communications  definition  numerical  ID  (NID)  of  the  instance. 

There  are  three  main  controls  for  the  application,  which  are  accessed  using  the  buttons  on  the 
application’s  toolbar.  Data  processing  is  initiated  either  manually  by  pressing  the  “Save”  icon  or 
as  part  of  the  CDP  system  by  the  VS  CnC  application  via  the  network.  Data  processing  is 
stopped  either  manually  by  pressing  the  “Stop”  icon  or  as  part  of  the  CDP  system  by  the 
VS  CnC  application  via  the  network.  System  configuration  is  accessed  by  pressing  the 
righthand  icon  (a  hand  pointing  at  a  document).  The  current  raw  sensor  output  values  (voltage 
for  the  IR  and  NIR  sensors,  counts  for  the  UV  sensor)  are  displayed  in  the  first  row  of  text  boxes. 
The  second  row  will  contain  the  background-corrected  and  scaled  sensor  values  once  data 
processing  has  been  started  and  a  20-second  (default)  background  sample  is  collected.  The  final 
row  of  indicators  indicates  the  status  of  the  SBVS  algorithm  outputs.  The  value  Sum_N  is 
similar  to  signal  amplitude  for  the  algorithms.  The  four  indicator  lights  turn  from  green  to  red 
when  the  corresponding  event  is  detected  by  the  SBVS  algorithms. 


Figure  7-4  -  SBVSLogger  main  screen,  system  idle 

7,3,  SBVSLogger  Standard  Configuration 

The  configuration  information  for  SBVSLogger  is  stored  in  two  places.  The  primary  location  is 
in  the  Windows  Registry  in  the  key  [HKEY_CURRENT_USER\Software\VB  and  VBA  Program 
SettingsXSBVSLogger] .  The  Stalwart  user  can  do  all  configuration  tasks  using  the  REGEDIT 
application  included  with  Microsoft  Windows.  A  complete  listing  of  the  reference  configuration 
for  the  CDP  is  included  in  Reference  10.  The  configuration  screens  of  the  SBVSEogger 
application  provide  a  simpler,  Ul-based  method  for  configuration.  The  configuration  screens  are 
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accessed  by  pressing  the  right  hand-most  button  on  the  application  toolbar  (the  hand  pointing  at  a 
page  icon).  The  network  eommunication  definition  for  each  instance  is  stored  in  an  .xml  file 
stored  at  a  location  indicated  in  the  windows  registry.  An  example  is  given  in  Referenee  10. 

The  SBVSLogger  configuration  is  split  into  three  Options  tabs.  The  first  tab  is  the  ‘Data 
Logging”  tab,  shown  in  Figure  7-5.  There  are  two  methods  available  for  automatically 
generating  SB  VS  filenames,  the  radio  buttons  on  this  tab  allow  the  user  to  choose  which  method 
is  used.  The  Date/Time  method  is  preferred.  The  main  configuration  option  on  this  screen  is  the 
location  for  storing  SBVS  data  files.  A  standard  Windows  interface  is  provided  for  choosing  a 
directory  for  storing  data  files  and  for  making  a  new  directory  from  within  the  program. 


Figure  7-5  -  SBVSLogger  Data  Logging  Options  Screen 

The  next  tab  is  the  ‘Device  Connections’  tab,  shown  in  Figure  7-6.  This  is  where  the  Fieldpoint 
Unit  inputs  are  mapped  to  the  raw  data  channels  of  the  SBVSLogger  application  for  a  given 
instanee.  First,  an  instance  is  selected  (existing  or  new).  Then  a  deseriptor  text  string  is 
provided  for  clarity.  This  string  is  used  in  no  other  place.  The  last  item  on  the  first  line  is  the 
selection  of  which  sensor  head  is  connected  by  the  device  serial  number.  This  tells  the 
SBVSLogger  applieation  what  calibration  information  to  use  to  scale  the  raw  data.  Two 
connection  strings  are  then  listed  whieh  map  analog  input  (-AI)  and  counter  (-CTR)  Fieldpoint 
modules  to  the  instances.  Below  each  are  the  specific  channel  mappings  for  the  module  and 
instanee. 
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To  remap  the  eonnection  string  which  maps  a  specific  cFP  module  (-AI  or  -CTR)  in  a  specific 
Fieldpoint  Unit  to  the  selected  instance,  the  user  presses  the  ‘browse’  button.  After  navigating  to 
the  desired  module,  a  specific  channel  must  be  selected  to  complete  the  process.  Flowever,  this 
channel  selection  is  not  used.  Instead,  the  row  of  channels  below  each  connection  string  is  then 
used  to  map  individual  channels  to  the  SBVSLogger  application  data  channels.  In  the  example, 
the  missing  590  and  766.5  nm  channels  are  mapped  to  the  grounded  channel  7.  For  the  counter 
input,  a  sparsing  factor  is  specified.  This  setting  tells  the  program  how  long  to  count  pulses  for  a 
reasonable  signal  level  to  be  achieved.  If  the  analog  inputs  are  set  to  10  Hz,  a  sparsing  factor  of 
10  sets  a  one  second  counting  period  for  the  UV  sensor. 

The  final  tab  is  the  “System  Definitions”  tab,  shown  in  Figure  7-7.  This  tab  allows  the  user  to 
specify  location  of  the  network  configuration  definition  files  that  control  the  network 
communications  of  the  SBVSLogger  instance.  Any  valid  system  definition  file  (up  to  three 
total)  in  the  specified  directory  will  be  used. 


Figure  7-6  -  SBVSLogger  Device  Connection  Options  Screen 
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Figure  7-7  -  SBVSLogger  System  Definitions  Options  Sereen 

7,4,  SBVSLogger  Extended  Configuration 

The  eonfiguration  options  diseussed  in  the  previous  section  are  those  that  typically  vary  from 
installation  to  installation.  There  are  additional  configuration  options  that  do  not  typically 
require  modification.  If  the  application  is  launched  with  a  negative  instance  number,  for 
example, 

"C:\Volume  Sensor  Programs\SBVS_Logger\Version  3.2.1  CA\SBVSLogger.exe"  -1 

The  SBVSLogger  Setup  Screen  can  be  accessed,  as  shown  in  Figure  7-8.  Here  it  is  possible  to 
select  which  of  the  five  possible  analog  inputs  from  the  VSP  SBVS  Component  Prototype  are 
active  and  the  names  displayed  for  them  in  the  main  screen.  The  active  state  of  the  counter  input 
can  also  be  controlled  here.  For  CDP  use,  the  first  four  analog  inputs  and  the  counter  input 
should  remain  active  and  the  fifth  analog  input  should  remain  inactive.  Also  the  persistence 
requirement  for  the  five  SBVS  Component  algorithms  can  be  set.  Note  that  for  a  new 
installation,  all  persistence  values  are  set  to  5  seconds  by  default.  The  analog  data  sampling  rate 
is  also  set  here,  10  Hz  by  default.  The  number  of  data  samples  to  acquire  at  the  beginning  of 
data  processing  is  also  set  here  with  a  default  of  200  samples  (20  seconds  at  10  Hz).  The  ‘Use 
Photodiode”  checkbox  controls  the  use  of  all  photodiodes  in  the  event  algorithms.  For  CDP  use, 
this  checkbox  should  remain  checked.  The  final  set  of  checkboxes  controls  what  output  options 
are  active.  The  ‘Scaled’  checkbox  controls  whether  or  not  the  scaled  sensor  values  are  saved  to 
the  local  data  files.  The  ‘Retain’  checkbox  controls  whether  or  not  the  local  data  file  is  saved  if 
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the  only  active  data  request  is  a  network  request  from  a  VS_CnC  request.  The  “VSCS” 
checkbox  controls  whether  or  not  all  network  communications  traffic  is  logged  locally  for 
debugging  purposes.  All  of  the  shown  settings  are  the  recommended  values. 


Figure  7-8  -  SBVSLogger  Setup  Screen 

7,5,  SBVSLogger  Operation 

The  SBVSLogger  application  can  be  launched  in  one  of  three  ways:  1)  double-clicking  on  the 
executable  or  an  associated  shortcut  and  selecting  the  desired  instance,  2)  launching  from  the 
command  line  (or  batchffie)  with  the  instance  number  specified,  or  3)  by  double-clicking  on  an 
associated  shortcut  with  the  instance  number  specified  in  the  command  line  arguments.  Options 
2  and  3  are  recommended  for  unattended  operation.  An  example  target  for  a  shortcut  to  launch 
instance  1  is: 

"C:\Volume  Sensor  Programs\SBVS_Logger\Version  3.2.1  CA\SBVSLogger.exe"  1 

If  the  instance  is  properly  configured,  the  application  will  launch  and  run  in  the  idle  state  as 
shown  in  Figure  7-4.  When  a  ‘start  data  processing’  command  is  received  either  locally  or  from 
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a  network  VS  CnC,  background  collection  will  commence.  The  main  screen  will  change  to 
reflect  the  application’s  operating  status,  as  shown  in  Figure  7-9.  After  the  background 
collection  period  is  over,  the  system  reaches  the  data  processing  stage  where  all  incoming  data 
are  evaluated  by  the  five  algorithms,  as  shown  in  Figure  7-10.  When  one  of  the  algorithms 
detects  an  event,  the  status  indicators  on  the  display  change  to  indicate  the  detected  events.  In 
Figure  7-11,  two  SB  VS  EVENTS  are  indicated,  EVENT  and  EIRE_EOV. 


Eigure  7-9  -  SBVSEogger  main  screen,  system  collecting  background  data 


Eigure  7-10  -  SBVSEogger  main  screen,  system  processing  incoming  data 
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Figure  7-1 1  -  SBVSLogger  main  screen,  system  detecting  a  FIRE  FOV  EVENT 

7,6,  Sensor  Head  Calibration 

To  handle  sensor-to-sensor  variability  in  response,  a  unique  set  of  Scale  Factors,  or  calibration 
factors,  need  to  be  generated  for  each  sensor  head.  These  Scale  Factors,  coupled  with  the 
averaged  background  data  from  each  test  run,  are  used  to  calculate  the  scaled  data  for  each 
sensor  from  the  raw  data.  The  mapping  of  Scale  Factors  to  SBVSEogger  instances  is  discussed 
in  Section  7.3. 

The  recommended  procedure  for  determining  the  Scale  Factors  for  a  sensor  head  is  outlined 
below.  It  is  recommended  to  also  measure  the  response  of  a  previously-calibrated  sensor  head  at 
the  same  time  as  a  cross-check.  The  sensors  should  be  powered  and  allowed  to  completely 
equilibrate  thermally,  preferably  for  several  hours  prior  to  calibration.  Each  unit  to  be  calibrated 
should  be  placed  at  roughly  eye  level.  A  calibration  lamp  is  then  used  to  provide  a  reference 
signal  to  each  sensor.  A  unit  similar  to  the  Senseware  T-229/1  UV/IR  OFD  test  lamp,  shown  in 
Eigure  7-12,  is  recommended.  The  T-229/1  is  basically  a  large  halogen  flashlight  with  a  5” 
diameter  reflector  and  a  metal  grill  in  place  of  the  typical  plastic  lens.  With  the  sensor  head 
powered  and  connected  to  the  Fieldpoint  Unit,  start  data  processing,  allow  the  background  to 
collect.  Then  illuminate  each  sensor  element  in  the  sensor  head  for  10  seconds  with  10  seconds 
of  background  in  between  each  sensor.  This  measurement  should  be  made  with  the  lamp  located 
at  distances  of  12  and  18  feet  from  the  sensor  head.  Due  to  the  sensitivity  of  the  NIR  sensor 
element,  the  1 8  feet  measurement  distance  is  required  to  get  an  unsaturated  measurement. 

Scaled  and  raw  data  are  related  by  the  Scale  Eactors  by  the  relationship; 

Raw  Data 

S calcd  Data  —  ~ — - - 

Scale  Factor 
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Figure  7-12  -  Senseware  T-229/1  UV/IR  OFD  test  lamp 

At  distances  of  12  and  18  feet,  the  response  due  to  the  T-229/1  Test  Lamp  should  yield  scaled 
data  as  indicated  in  Table  7-3. 


Table  7-3  -  Scaled  Data  Voltages  for  Standard  Test  Lamp  and  Distances 


Sensor  Element 

12’  Sealed  Data  (V) 

18’  Scaled  Data  (V) 

UV 

5.300 

IR 

0.080 

NIR 

22.2 

8.  Long-Wavelength  Video  Detection  (LWVD)  Component 

Routine  operation  of  the  LWVD  component  for  the  CDP  is  straightforward  and  requires  no 
operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is  required 
and  presented  in  this  Section.  The  information  in  this  Section  is  excerpted  for  Reference  1 1 . 

8,1,  LWVD  Data  Acquisition  Electronics 

Data  acquisition  (the  conversion  of  analog  signals  to  digital  information)  is  performed  by  a 
4-channel  frame  grabber  (IDS  Falcon  Quattro,  PCl-E  version)  installed  in  the  local  data 
processing  computer  (PC).  The  Falcon  Quattro  card  is  capable  of  simultaneously  capturing  4 
channels  of  live  video  at  the  full  analog  video  frame  rate,  29.97  Hz  for  NTSC.  While  the  frame 
grabber  is  capable  of  capture  video  of  a  variety  of  standards,  the  VS  software  provided  as  part  of 
the  CDP  assumes  that  the  video  sources  are  of  the  NTSC  format.  Standard  75-ohm  coaxial 
cables  are  used  to  connect  the  LWVD  camera  in  the  CDP  sensor  head  to  the  frame  grabber. 
Cable  lengths  of  greater  than  50  feet  should  include  the  use  of  video  amplifiers  to  prevent  signal 
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degradation.  The  electrical  connections  from  the  CDP  sensor  heads  to  the  data  processing  PC 
are  shown  in  Figure  8-1.  Analog  signals  are  shown  as  solid  lines.  An  external  view  of  the  frame 
grabber  backplane  is  shown  in  Figure  8-2  with  the  video  inputs  channels  labeled  for  reference. 
The  frame  grabber  provides  four  input  video  channels,  enough  to  operating  two  CDP  sensor 
heads  simultaneously  (two  video  channels  per  sensor  head,  two  sensor  heads). 


Figure  8-1  -  Schematic  Wiring  Diagram  for  the  LWVD  Component 


Figure  8-2  -  External  View  of  Frame  Grabber  Backplane  with  Inputs  Labeled 
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8.2.  LWVD  Software 

For  the  CDP,  the  intention  is  to  install  and  run  two  CDP  sensor  heads,  eaeh  with  a  color  video 
camera  and  a  NIR-filtered  black  and  white  camera,  for  a  total  of  four  video  feeds.  Both  black 
and  white  video  feeds  will  be  recorded  and  processed  by  the  LWVD  algorithm  for  event 
detection  purposes.  Both  color  video  feeds  will  be  recorded  only.  Given  the  desire  to  conduct 
all  CDP  data  collection  and  processing  on  a  single  PC  and  the  similarities  in  program 
requirements  for  the  color  and  black  and  white  video,  a  single  software  application  was 
developed  to  handle  any  one  video  input  based  on  the  configuration  file  used.  One  instance  of 
the  application  can  be  run  for  each  frame  grabber  input. 

The  LWVD  application  is  designed  to  run  in  one  of  two  modes,  depending  on  configuration.  In 
LWVD  mode,  the  application  is  designed  to  collect  video  data  from  a  single  input  of  the  local 
frame  grabber,  record  the  video  in  a  standard  video  format  (.  avi),  process  the  data  using  the  VS 
LWVD  Component  Prototype  algorithm,  and  pass  the  sensor  data  and  algorithm  results  to  the 
VS  Data  Fusion  Algorithm  via  the  VS  CnC  application.  In  DVR  mode,  the  application  is 
designed  to  collect  video  data  from  a  single  input  of  the  local  frame  grabber  and  record  the  video 
in  a  standard  video  format  ( .  avi).  While  the  LWVD  software  has  a  full  graphical  user  interface 
(GUI),  it  is  currently  intended  to  be  run  in  an  unattended  mode.  The  configuration  and  operation 
of  the  software  is  briefly  described  here. 

Upon  startup,  the  main  screen  of  the  LWVD  application  is  displayed,  as  shown  in  Figure  8-3. 
Each  video  camera  in  each  CDP  sensor  head  is  monitored  by  a  separate  instance  of  the  LWVD 
application.  The  title  bar  of  the  application  can  be  used  to  denote  which  instance  is  being 
monitored,  LWVD  1  in  Figure  8-3. 

In  LWVD  mode,  there  are  three  main  controls  for  the  application  which  are  accessed  using  the 
UI  buttons  on  the  main  screen.  Data  processing  is  initiated  either  manually  by  pressing  the 
“Start  Analysis”  button  or  as  part  of  the  CDP  system  by  the  VS_CnC  application  via  the 
network.  Data  processing  is  stopped  either  manually  by  pressing  the  “Stop  Analysis”  button  or 
as  part  of  the  CDP  system  by  the  VS  CnC  application  via  the  network.  While  data  processing  is 
occurring,  the  background  reference  frame  for  the  algorithm  can  be  changed  to  the  current  frame 
by  pressing  the  “Reset  Background”  button  (or  by  the  VS  CnC  application  via  the  network). 

The  current  video  frame  is  displayed  in  the  upper  left  corner  of  the  UI.  The  background 
reference  image  is  shown  in  the  upper  right  comer  of  the  UI  when  data  acquisition  is  underway. 
The  video  acquisition  input  source  and  video  recording  codec  settings  are  displayed  for  the 
operator  below  the  current  image.  Changes  can  only  be  made  in  the  configuration  file.  The 
indicator  light  in  the  middle  of  the  screen  turns  from  green  to  yellow  to  red  to  indicate  the  state 
of  the  LWVD  algorithm,  when  mnning.  The  frame  rate  of  video  processing  and  the  three 
parameters  of  the  LWVD  algorithm  are  indicated  in  the  center  section  of  the  UI,  when  data 
acquisition  is  underway. 


56 


User’s  Guide 


In  DVR  mode,  there  are  three  main  controls  for  the  application,  which  are  accessed  using  the  UI 
buttons  on  the  main  screen.  Video  recording  is  initiated  either  manually  by  pressing  the  “Start 
Save  AVI”  button  or  as  part  of  the  CDP  system  by  the  VS  CnC  application  via  the  network. 

Data  processing  is  stopped  either  manually  by  pressing  the  “Stop  Save  AVI”  button  or  as  part  of 
the  CDP  system  by  the  VS  CnC  application  via  the  network. 

For  either  mode,  the  LWVD  application  opens  the  configured  video  source  and  begins  video 
capture  immediately  on  application  startup.  The  real-time  video  stream  is  shown  continuously  in 
the  upper  left  image  panel.  If  data  processing  is  not  occurring,  it  is  possible  to  stop  video 
acquisition  and  either  adjust  the  DirectShow  configuration  parameters  for  the  video  source  or 
play  back  a  previously  recorded  video.  The  controls  for  these  functions  are  located  in  the  lower 
left  side  of  the  UI. 


Figure  8-3  -  LWVD  main  screen,  LWVD  mode,  system  idle,  no  data  acquisition 
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8.2,1.  LWVD  Configuration 

The  configuration  information  for  an  instance  of  the  LWVD  application  is  stored  in  a 
configuration  file  ( .  ini).  The  configuration  file  for  CDP  sensor  head  1,  LWVDl  is  shown  in 
File  Listing  8-1. 


File  Listing  8-1  -  Annotated  Version  of  LWVDl  Configuration  File  (iwvdl .  ini) 


LWVD4 010101 
1 

20 

sysdef_LWVD01_CnCl . xml 

F:\LWVD  Data  Files 
0 

LWVD  1 

LWVDmemf ilemap_l 
1 

70 


-  Root  filename  for  data  files 

-  Source  video  input,  range:  1-4 

-  Video  codec  selection,  range  and  values  vary 

-  Network  communications  configuration  definition  filename (s), 
space  delimited 

-  Path  for  data  file  storage 

-  Mode  Selection:  0  =  LWVD  mode,  1  =  DVR  mode 

-  Text  for  program  title  bar 

-  Memory  buffer  for  VS_Quad  application 

-  Pixel  value  for  top  edge  of  UI  screen 

-  Pixel  value  for  left  edge  of  UI  screen 


While  most  of  these  settings  are  self  explanatory,  a  few  require  additional  discussion.  The 
easiest  way  to  determine  the  proper  index  value  for  the  desired  video  codec  is  to  open  the 
LWVD  application  and  read  the  index  number  off  the  list  of  available  video 
compressors/decompressors  (codecs)  in  the  UI.  This  list  will  show  all  codecs  installed  on  the  PC 
that  can  be  used.  If  no  compression  is  desired,  index  0  should  be  selected.  The  current 
recommended  code  is  the  Xvid  codec  (vL2.2)  [12],  For  the  top  and  left  values  for  the  UI  screen, 
the  example  above  in  File  Listing  8-1  indicate  top,  left  coordinates  of  (70,1),  or  70  pixels  to  the 
right  and  one  pixel  down  from  the  upper  left  comer  of  the  screen.  As  a  note,  the  coordinates 
(0,0)  refer  to  the  center  of  the  screen,  not  the  expected  top,  left  corner  of  the  screen.  The 
network  communication  configuration  definition  for  each  instance  is  stored  in  an  .xml  file  at  the 
location  indicated  in  the  configuration  file.  The  LWVDl  configuration  file  for  the  CDP  is  listed 
in  Reference  1 1 . 


While  not  expected  to  be  a  routine  configuration  task,  each  video  input  source  needs  to  be 
configured  once  per  computer  to  the  NTSC  format.  From  a  mnning,  but  idle  instance  of  the 
LWVD  application,  stop  video  acquisition  by  pressing  the  “Stop  Video  Src”  UI  button.  Then 
press  the  “Configure  Video  Src  . . .”  UI  button.  Then  select  “NTSC  M”  as  the  video  source,  as 
shown  in  Figure  8-4.  Click  “OK”  to  save  the  configuration.  This  function  must  be  performed 
for  each  video  source  channel. 
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Figure  8-4  -  Video  Source  Configuration  Screen,  NTSC  format  selected 

8,2,2,  LWVD  Operation 

The  LWVD  application  can  be  launched  in  one  of  two  ways;  1)  launching  from  the  command 
line  (or  batchfile)  with  the  desired  configuration  file  specified,  or  2)  by  double-clicking  on  an 
associated  shortcut  with  the  desired  configuration  file  specified  in  the  command  line  arguments. 
If  no  configuration  file  is  specified  at  launch,  such  as  would  happen  if  the  executable  was 
double-clicked  on  in  Windows  Explorer,  the  default  configuration  as  specified  in  the  default 
configuration  file  (default .  ini)  located  in  the  binary  directory  is  used.  An  example  target  for 
a  shortcut  to  launch  LWVDl  is: 

"C:\Volume  Sensor  Programs\LWVD_2010_VS_Quad\LWVD.exe"  lwvdl.ini 

If  the  instance  is  properly  configured,  the  application  will  launch  and  run  in  the  idle  state  as 
shown  in  Figure  8-3  for  the  LWVD  mode.  When  a  ‘start  data  processing’  command  is  received 
either  locally  or  from  the  VS_CnC  via  the  network,  data  processing  will  commence  with 
background  data  collection.  Video  recording  and  data  logging  also  commence.  The  main  screen 
will  change  to  reflect  the  application’s  operating  status,  as  shown  in  Figure  8-5.  After  30 
seconds,  the  background  collection  period  is  over  and  the  reference  frame  is  logged.  The 
reference  frame  is  written  to  disk  as  an  image  file  ( .  bmp)  and  the  luminosity  threshold  value  for 
event  detection  is  determined.  All  incoming  data  are  then  evaluated  by  the  LWVD  algorithm. 
When  the  algorithm  detects  a  luminosity  value  above  the  specified  event  detection  threshold,  the 
algorithm  moves  into  an  event  classification  mode.  As  the  algorithm  status  is  updated,  the 
indicator  on  the  display  changes  from  OK,  to  Pre- Alarm,  and  then  to  Alarm  to  indicate  the 
evolving  event  condition.  In  Figure  8-6,  the  algorithm  status  of  ‘Pre-Alarm’  indicates  that  the 
algorithm  is  in  pre-alarm  and  that  if  the  condition  persists,  an  ‘Alarm’  condition  will  be  reached 
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in  the  near  future  as  shown  in  Figure  8-7.  When  a  ‘stop  data  processing’  command  is  received 
either  locally  or  via  the  network,  data  processing  stops  and  all  data  files  are  closed. 


Operation  for  the  DVR  mode  is  similar,  except  no  data  processing  is  conducted  and  the  only  data 
file  generated  is  the  recorded  video  file. 


Figure  8-5  -  LWVD  main  screen,  system  processing  incoming  data 
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Figure  8-6  -  LWVD  main  screen,  system  in  FIRE  pre-alarm  state 
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Figure  8-7  -  LWVD  main  screen,  system  in  a  FIRE  alarm  state 

8.2.3.  LWVD  Data  Files 

The  LWVD  system  collects  data  in  several  data  files.  For  the  LWVD  mode,  there  are  three  types 
of  data  files:  1)  the  data  log  file  (* .  txt,  ASCII  format);  2)  the  reference  video  frame  used  for 
determining  the  event  detection  threshold  ( *  .  bmp,  Windows  bitmap  format);  3)  the  recorded 
video  file  (* .  avi,  .AVI  format).  Lor  the  DVR  mode,  there  is  only  one  data  file,  the  recorded 
video  file  (* .  avi,  .AVI  format). 

An  example  data  log  file  is  given  in  Reference  1 1 .  For  the  LWVD  data  log  files,  the  file  naming 
convention  is  ‘Pref  ix_LogFile_MMDDYYYY_HHmmss  .  txt’,  for  example 

‘LWVD40l0l0l_LogFile_052820l0_l4l328.txt’.  A  partial  listing  of  an  example  is  given  in 
Reference  1 1 . 
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The  file  naming  conventions  for  the  background  image  file  and  video  recording  files  are: 


PREFIX_BackgroundImage_MMDDYYY_HHmmss_at-HHmmss . bmp 
PREFIX  Video  MMDDYYYY  HHmmss.avi 


The  value  of  ‘prefix’  is  determined  by  the  first  line  in  the  configuration  file.  The 
‘MMDDYYYY_HHmmss’  Is  the  time  at  whlch  data  processing  began  and  is  common  with  all  data 
files.  The  ‘  at-HHmmss’  portion  of  the  background  image  filename  reflects  the  time  that  he 
background  image  was  acquired. 

9.  Acoustics  (ACST)  Component 

Routine  operation  of  the  Acoustics  component  for  the  CDP  is  straightforward  and  requires  no 
operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is  required 
and  presented  in  this  Section.  The  information  in  this  Section  is  excerpted  from  Reference  13. 

9.1,  Acoustics  Hardware  and  Processing  Overview 

Figure  9-1  shows  a  schematic  of  the  acoustics  hardware  and  processing.  The  microphone  in  the 
CDP  sensor  unit  on  the  left  of  the  figure  is  an  AKG  C-417  lavalier  microphone  commonly  used 
by  speakers  making  presentations.  The  signal  passes  along  the  cable  to  a  phantom  power 
supply,  which  provides  48V  DC  to  power  the  microphone.  The  signal  passes  through  the 
phantom  power  supply  to  the  Lynx  TWO  24-bit  A/D  card.  This  card  digitizes  the  signal  and 
passes  the  results  to  the  Eventoetector  program  running  on  the  computer.  Based  on  the  four 
input  configuration  files,  the  program  processes  the  acoustic  data  and  passes  results  to  the  Fusion 
Machine.  The  passing  of  results  to  the  Fusion  Machine  is  started  and  stopped  by  commands 
from  the  Fusion  Machine  software  resident  on  the  same  computer. 


^  The  audio  system  can  handle  up  to  4  sensor  units. 
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CDP  Sensor  Unit 


AKG  C-417 
Microphone 


Phantom 

Power 

Supply 


Computer 


LynxTWO 
24-bit  A/D  Card 


Optional  Output  Files 

•  CA\/S_YYYYMMDD-hhmmss.sr\(i 

•  C/WSJDei_YYYYMMDD-hhmmss.m 
•CAVS  SV  YYYYMMDD-hhmrnssm 


Fusion  Machine 

t 

CPU 

cveiiiueitJClur 

Configuration  Files 

•  FM1-ACST2.xml 

•  Microphones.id 

•  Lynx_Config.ini 

•  VS5_Coefs.reg 


Figure  9-1  -  System  overview  of  the  acoustics  data  acquisition  and  processing  for  the  Canadian 
Demonstrator  Prototype  system. 

Each  CDP  sensor  unit,  fabricated  by  Vibro-Meter,  Inc.,  contains  six  individual  sensor  elements. 
The  CDP  sensor  unit  is  shown  in  Figure  9-2.  Two  video  cameras  are  included,  one  color  CCTV 
camera  (lower  center),  and  one  low-pass  (NIR)  filtered  black  and  white  CCTV  camera  (lower 
right).  Three  non-imaging,  spectral-based  sensor  elements,  mid-IR  (4.3  pm,  center  right),  UV 
(upper  left),  and  NIR  (1050  nm  (lower  right)  complete  the  spectral  sensing  suite.  Finally,  the 
audio  microphone  is  located  in  the  small  hole  in  the  upper  right  corner,  protruding  just  slightly. 


Figure  9-2  -  Front  view  of  the  Canadian  Demonstrator  Prototype 
Sensor  Unit  with  the  acoustics  sensor  in  the  upper  right  comer. 
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Figure  9-3  shows  the  back  of  the  CDP  sensor  unit  with  the  wires  emerging  from  the  hole  in  the 
rear.  The  acoustics  wire  is  the  thinnest  one.  It  connects  to  a  shorter  converter  cable  that  adapts 
the  lavalier  microphone  cable  to  a  standard  XLR  cable.  The  more  robust  XLR  cable  then  runs  to 
the  computer.  The  XLR  cable  provides  the  48V  DC  power  to  the  microphone  through  the 
converters.^ 


Figure  9-3  -  Rear  view  of  the  Canadian  Demonstrator  Prototype  Sensor 
Unit  with  the  acoustics  cables  and  connectors  in  front. 

Figure  9-4  shows  the  hardware  at  the  computer  end.  The  signal  arrives  from  the  sensor  units  on 
the  XLR  cables  that  are  plugged  into  a  48V  DC  phantom  power  supply.  The  unit  supplied  is  a 
Stewart  Audio  PM-4,  which  can  power  up  to  4  microphones.  The  power  supply  then  connects  to 
the  LynxTWO  24-bit  A/D  card  in  the  computer  by  the  cables  shown  in  the  figure.  The  card 
provided  is  the  A  model  and  has  eight  channels,  four  inputs  and  four  outputs.^ 

Once  inside  the  computer  and  converted  to  digital  representation  by  the  A/D  card,  the  data  are 
passed  to  the  Eventoetector  program  for  analysis.  This  program  analyzes  the  signal 
characteristics  on  an  ongoing  basis  and  provides  results  to  the  Fusion  Machine  for  further 
analysis  and  handling. 


From  experience,  the  XLR  can  safely  be  run  at  least  50  ft  with  no  problems.  An  upper  limit  for  XLR  cable  length 
has  not  been  determined. 

^  There  are  B  and  C  models  that  differ  by  varying  the  number  of  input  and  output  channels,  2/6  and  6/2. 
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Figure  9-4  -  Computer  eonneetions  showing  the  acoustics  A/D  card  (on  bottom),  connecting 
cables,  and  the  phantom  power  supply. 


9,2,  Acoustics  Processing  Software  and  Control  Files 
9,2,1,  Acoustics  Processing 

The  principal  component  of  the  acoustic  processing  software  is  the  EventOetector  program. 
The  acoustics  processing  is  centered  on  a  linear  discriminant  algorithm  used  to  classify  noise 
according  to  the  characteristics  of  the  audio  spectrum.  This  program  monitors  the  ambient  noise 
in  a  compartment  and  when  sounds  typical  of  an  event,  such  as  water  falling  are  detected,  it 
reports  a  pipe  rupture  or  other  event  based  on  the  noise  detected.  This  is  done  through  two  types 
of  data  passed  to  the  Fusion  Machine,  channel  data  and  alarm  status  for  each  event.  The  channel 
data  represent  an  estimate  of  the  probability  of  an  event.  As  an  event  persists,  the  alarm  level  is 
continually  raised  until  sometime  after  3  seconds  it  is  considered  fully  set  and  an  event  is 
formally  considered  detected.  Table  9-1  lists  the  different  types  of  events  looked  for  by  the 
acoustic  processing  software.  The  abbreviation  column  is  used  in  real-time  monitoring  of  the 
processing  in  a  terminal  window. 
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Table  9-1  -  Audio  Events  and  Alarms 


Event 

Abbreviation 

Alarm  Type 

Sensor  Overload 

0 

Event 

Background  Noise 

N 

Background 

Water 

W 

Pipe  Rupture 

Mist 

M 

Event 

Gas  Leak 

G 

Event 

Torch 

T 

Nuisance 

Grinding 

R 

Nuisance 

Welding 

L 

Nuisance 

Engine 

E 

Nuisance 

People 

P 

Nuisance 

Activity 

H 

Nuisance 

The  first  event,  sensor  overload,  is  processed  before  the  others.  The  channel  data  and  alarm 
status  for  this  event  represent  the  percentage  of  the  data  believed  to  be  overloaded.  Full  scale  is 
1%  of  the  time  series  points  on  the  channel.  This  alarm  is  set  faster  than  the  others,  activating 
immediately  if  the  1%  threshold  is  reached.  If  this  condition  is  observed  all  other  alarms  must  be 
considered  suspect.  After  testing  for  overloads,  the  program  then  Fourier  transforms  the  data  in 
0.2  s  chunks,  overlapping  the  previous  chunk  by  0.1  s  or  50%.  Once  every  second,  based  on  the 
previous  5  s  of  results,  it  calculates  270  parameters;  mean  levels  in  200  Hz  bands,  standard 
deviations,  skew,  slopes,  number  of  lines,  transients,  and  A-weighted  mean  level,  standard 
deviation,  and  skew.  These  parameters  are  normalized  and  then  multiplied  by  the  regression 
coefficients  to  obtain  channel  measures  that  are  then  converted  to  probabilities  and  the  alarm 
state  raised  or  lowered  according  to  the  probabilities.  There  is  a  separate  algorithm,  based  on  the 
high  frequency  slope  of  the  spectra,  looking  for  water  events.  If  this  algorithm  detects  something 
it  will  increase  the  probability  of  a  water  event  resulting  in  a  faster  detection. 

Background  noise,  the  null  state,  is  based  on  the  last  3  minutes  of  data.  As  such,  when  running 
tests  it  is  desirable  to  give  the  processing  3  minutes  to  start  up.  The  system  is  set  up  so  that  if  an 
event  is  not  found  in  a  stable  noise  environment  the  background  noise  characterization  will 
adjust  to  the  new  noise  environment.  This  reliably  handled  changes  in  ventilation  strength 
aboard  the  ex-USS  SHADWELL. 

State  vector  data,  composed  of  channel  data  and  alarm  data,  are  not  sent  to  the  Fusion  Machine 
until  specifically  requested.  EventOetector  begins  running  immediately  when  the  program  is 
started  and  thus  a  noise  background  level  may  be  well  established  before  the  Fusion  Machine 
requests  the  state  vector  data. 

Obviously,  an  event  is  only  detectable  if  its  significant  characteristics  rise  above  the  background 
noise.  Foud  enough  noise  can  mask  all  events. 
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9.2,2,  Software  and  Control  Files 

The  acoustics  processing  software  is  located  in  the  Acoustic  directory  currently  set  as 
‘c:\Volume  Sensor  Programs\ACST\ Within  this  directory  are  8  files,  listed  in  Table  9-2, 
necessary  for  the  proper  function  of  the  acoustic  processing  software.  Of  these  eight  files,  the 
first  three  files  listed  in  Table  9-2  are  the  code  executed  during  the  running  of  the  audio 
processing.  The  fourth  file  is  a  temporary  file  used  in  communications  with  the  Fusion  Machine. 
The  last  four  files  are  text  files,  which  under  certain  circumstances  may  need  to  be  edited. 
However,  only  one  of  these.  Microphones .  id,  should  be  edited  under  normal  circumstances. 

Table  9-2  -  Acoustic  Directory  Files 


acst  server.exe 

Talks  to  the  Fusion  Machine  to  receive  start,  stop,  status  commands 
and  to  send  the  data  messages. 

Audio  Capture.dll 

Library  containing  the  routines  to  start,  read  and  close  data 
acquisition. 

EventDetector . exe 

Main  acoustic  processing  program. 

input  command  log.txt 

Used  to  temporarily  store  file  names  of  Fusion  Machine  commands 
until  EventDetector.exe  can  process  them. 

Lynx  Config.ini 

LynxTWO  configuration  file,  which  contains  only  one  parameter  to 
set  a  debug  mode.  See  listing  in  Reference  13. 

FM1-ACST2 .xml 

System  definition  file.  See  discussion  below  and  listing  in 

Reference  13. 

Microphones . id 

Sensor  identification  file.  See  discussion  and  listing  below. 

VS5  Coefs.reg 

Regression  coefficients  file.  See  discussion  below  and  listing  in 
Reference  13. 

Lynx_Conf  ig .  ini  is  the  configuration  file  for  the  LynxTWO  audio  card.  All  features  of  the 
Lynx  TWO  software  are  hardwired,  except  for  a  debugging  option  available  in  this  file.  The  user 
should  not  change  this  file  unless  they  have  spent  the  time  to  become  familiar  with  the  software 
used  to  run  the  LynxTWO  data  acquisition  card.  fmi-asct2  .  xml  is  the  system  definition  file. 
This  file  defines  the  interface  to  the  Fusion  Machine  and  should  be  changed  only  in  coordination 
with  that  program.  Specifically,  it  contains  port  and  IP  address  information  that  may  need  to  be 
changed  when  setting  up.  This  file  formally  defines  the  state  vectors  containing  the  channel  data 
and  alarm  status  for  each  type  of  event.  The  file  contains  the  information  for  the  maximum 
number  of  sensors  that  can  be  processed  by  EventOetector,  which  is  4. 

Microphones .  id  is  the  scnsor  identification  file.  This  file  tells  the  audio  processing  what 
sensors  are  available.  File  Listing  9-1  shows  the  contents  of  the  file  as  shipped.  The  format  is 
very  simple;  the  first  line  is  the  number  of  channels  and  must  be  an  integer  value  between  1  and 
4.  Then  on  the  next  1  to  4  lines  are  listed  the  sensor  type.  Currently  they  are  all  set  to  cavs_Box. 
Finally,  an  additional  line  may  be  added  to  request  files  to  be  put  out  with  the  raw  acoustic  data 
and  processing  results.  This  option  is  the  subject  of  Section  9.4. 
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File  Listing  9-1  -  Sensor  Identification  File,  Microphones .  id 


3, 

CAVS_Box 

CAVS_Box 

CAVS_Box 

The  other  sensor  options  available  are  provided  in  Table  9-3.  The  Shure  MX-393  and  MX-202 
microphones  were  used  extensively  during  developmental  work.  The  Shure  KSM-141  is  a 
studio-grade  microphone  with  wide  dynamic  range  and  fiat  response  and  was  used  as  a  reference 
to  establish  the  sensitivity  and  frequency  response  of  the  CDP  sensor  unit.  System  sensitivity 
and  frequency  response  factors  for  these  microphones  are  defined  in  the  software.  Using  other 
sensors  will  require  modification  of  the  software.  The  microphone  in  the  CDP  sensor  unit  is  the 
AKG  C-147L.  The  sensitivity  and  frequency  response  have  been  experimentally  determined  and 
included  in  the  software  to  adjust  for  the  presence  of  the  box  around  the  microphone. 


Table  9-3  -  Valid  Sensor  Options 


Sensor  Names 

Sensor  Description 

AKG  C-577-WR 

AKG  water-resistant  lavalier  microphone 

AKG  C-147L 

AKG  lavalier  microphone 

CAVS  Box 

CDP  Advanced  Volume  Sensor  unit  with  AKG  C-147L  inside 

Shure  KSM-141 

Shure  extended-range,  studio  microphone 

Shure  MX-183-0 

Shure  wired  lavalier  microphone 

Shure  MX-202-O 

Shure  hanging  microphone  used  for  choirs  and  performance  groups 

Shure  MX-393-0 

Shure  surface  mounted,  boundary  effect,  microphone 

The  final  file,  vss  coef  s .  reg,  is  the  regression  coefficients  file.  It  includes  parameters  and 
scalings  necessary  for  the  acoustic  processing  to  work.  It  is  used  to  calculate  probabilities  of  an 
event  having  occurred.  This  file  should  not  be  modified. 

9.3.  Acoustic  Installation  and  Operating  Instructions 

9.3.1.  Hardware  Installation  Instructions 

Refer  to  Figure  9-3  and  Figure  9-4  as  indicated. 

1 .  Verify  that  the  Lynx  TWO  card  is  properly  seated  in  the  computer.  (Figure  9-4)  If  it  is 
not  installed,  refer  to  the  LynxTWO  User’s  Manual  or  Quick  Start  Guide,  Refs. 

[14  &  15],  for  installation  instructions. 
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2.  Connect  the  Lynx  Audio  cable  (Lynx  part,  CBL-L2AUDIO)  to  the  audio  port  and  secure 
it.  (Figure  9-4) 

3.  Connect  the  analog- in  cables  labeled,  “IN-1”  and  “IN-2”  of  the  audio  cable  to  the  Stewart 
phantom  power  supply.  (Figure  9-4)  If  more  channels  are  being  used  connect  cables 
“IN-3”  and  “IN-4”  as  needed. 

4.  Connect  the  appropriate  XLR  microphone  cables  to  the  phantom  power  unit  and  string 
each  to  the  appropriate  CDP  unit.  (Figure  9-4)  Verify  that  the  proper  unit  is  being 
connected  to  the  proper  audio  channel.  Generally,  CDP  unit  1  to  audio  “IN-1”,  etc. 

5.  Attach  the  XLR-lavalier  microphone  converter  cable  to  the  XLR  cable  and  the  small 
cable  from  the  CDP  unit.  (Figure  9-3) 

6.  Plug  the  power  supply  for  the  Stewart  phantom  power  supply  into  a  standard  wall  socket 
and  into  the  phantom  power  unit.  (Figure  9-4) 

9,3,2,  Software  Installation  and  Operating  Instructions 


During  normal  operation  the  functioning  of  the  acoustic  system  is  automatic  and 
the  user  needs  only  to  verify  the  presence  of  the  configuration  files  and  that  they 
contain  the  proper  contents  as  described  in  Section  9.2.  In  particular,  verify  that 
Microphones .  id  contains  the  proper  contents. 


The  acoustic  software  will  launch  automatically  when  the  command  file  is  used  to  start  all 
components  of  the  CDP  Volume  Sensor  system.  At  this  time  an  acoustics  display  window  will 
appear  that  monitors  the  status  of  the  acoustic  processing.  The  window  will  update  at  1  s 
intervals  with  the  noise  level  (dBA)  and  the  alarm  status  for  each  event  on  a  single  line  for  all 
channels.  When  an  alarm  is  building  towards  being  set  (value  of  1 .00),  it  is  presented  as  a  lower 
case  letter  for  which  the  abbreviation  can  be  found  in  Table  9-1 .  When  an  alarm  is  reached  it 
appears  as  an  upper  case  letter.  When  the  alarm  state  is  essentially  zero  a  decimal  point  is 
substituted  for  the  letter.  It  will  not  start  sending  state  vector  information  until  instructed  to  by  a 
start  command  received  from  the  command  and  control  component  of  the  Fusion  Machine 
software.  It  will  stop  sending  state  vector  information  when  a  stop  command  is  received,  but  the 
software  will  continue  to  run.  Both  of  these  commands  will  be  displayed  in  the  display  window 
when  received.  It  is  recommended  that  the  acoustics  software  be  stopped  by  typing  a  “q”  in  the 
acoustics  display  window. 

9,4,  Testing  Mode 

As  noted  in  Section  9.2,  a  testing  mode  can  be  initiated  by  changing  the  Microphones .  id  file 
to  include  a  final  line  listing  an  output  directory  for  storing  audio  data  files.  An  example  is 
provided  in  File  Listing  9-2.  The  directory  shown  is  a  directory  used  during  system  testing,  but 
any  valid  directory  is  acceptable.  When  the  final  line  exists,  EventOetector  will  create  3 
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output  files;  a  sound  file  eontaining  the  raw  data  with  a  header,  a  state  veetor  file  eontaining  the 
ehannel  data  and  alarm  status  for  eaeh  event  type  and  sensor,  and  a  deteetions  file  eontaining  the 
first  time  eaeh  alarm  triggered.  These  files  are  only  ereated  when  data  are  requested  by  the 
Fusion  Maehine  and  are  best  used  when  running  a  series  of  tests  with  EventOetector  not 
sending  data  between  events. 

NOTE:  It  is  important  to  not  leave  the  testing  mode  aetive  under  normal  operating  eonditions 

as  the  sound  and  state  veetor  files  ean  beeome  exeessively  large. 

File  Listing  9-2  -  Sensor  Identifieation  File,  Microphones .  id,  with  Testing  Mode  Aetivated 

3, 

CAVS_Box 

CAVS_Box 

CAVS_Box 

F:\ACST  Data  Files\ 

The  sound  data  file  is  labeled  in  the  format  CAVS_YYYYMMDD-hhmmss .  snd,  where  year,  month, 
day,  hour,  minutes,  and  seeonds  of  the  start  time  of  the  file.  In  eaeh  file  will  be  a  header  with 
information  on  the  sampling  rate,  number  of  ehannels  and  time  points  and  the  system  gain 
applied  to  the  data.  The  latter  is  the  system  gain  for  the  first  channel.  The  data  have  not  been 
corrected  for  the  frequency  response.  Thus  the  data  for  the  2"^^  through  4**^  channels  will  need  to 
be  corrected  for  system  gain  if  they  are  not  the  same  type  of  sensor  as  the  first  channel.  All 
channels  will  need  to  be  corrected  for  the  frequency  response  of  the  sensor. 

The  second  file  is  the  state  vector  file,  labeled  CAVs_sv_YYYYMMDD-hhmmss .  txt.  This  is  a  text 
file  labeled  with  the  same  date-time  string  as  the  sound  file.  This  file  contains  the  contents  of  the 
state  vectors  sent  to  the  Fusion  Machine  every  second  while  running.  The  structure  is  as  follows: 

1.  Time  in  hh:mm:  ss .  sss  format,  hours,  minutes  and  seconds. 

2.  Noise  level  in  dBA  units  for  channel  1 . 

3.  Overload  alarm  status  for  channel  1. 

4.  Channel  data  and  alarm  status  for  each  of  the  final  10  events  in  Table  9-1  for  channel  1. 
20  positions. 

5.  Noise  level,  overload  alarm  status  and  event  status,  channel  data  and  alarm,  for  each  of 
the  remaining  channels.  22  positions  for  each  channel,  repeating  items  2-4. 

The  third  file  produced  is  the  detections  file,  labeled  CAVs_Det_YYYYMMDD-hhmmss .  txt.  This  is 
a  text  file  labeled  with  the  same  date -time  string  as  the  sound  and  state  vector  files.  This  file 
contains  a  single  line  with  the  times  of  the  detections  for  each  event  and  channel  on  a  single  line. 
The  format  is  date  information  followed  by  time  for  the  events  in  each  channel.  Note  that  the 
second  time  is  the  noise  time  and  should  be  the  time  that  processing  was  started  for  the  event. 
This  file  is  only  written  if  the  event  is  properly  terminated  with  a  stop  command. 
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10.  SigniFire  Machine  Vision  (VID)  Component 

Routine  operation  of  the  SigniFire  VID  component  for  the  CDP  is  straightforward  and  requires 
no  operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is 
required  and  is  presented  in  this  Section.  The  information  in  this  Section  is  excerpted  for 
Reference  16. 

10,1,  SigniFire  IP  Physical  Configuration 

The  core  of  the  SigniFire  system  is  the  SigniFire  IP  network  camera,  as  shown  in  Figure  10-1. 


Figure  10-1  -  SigniFire  IP  Camera  a)  14  profile  view  b)  rear  view 

Details  on  the  specifications  and  configuration  of  the  SigniFire  IP  camera  are  available  in 
Reference  17.  Each  camera  is  provided  with  an  adjustable  focal-length  lens.  The  cameras  are 
powered  using  Power-over-Ethemet  (PoE)  or  optionally  from  an  external  12  VDC  supply.  PoE 
is  used  for  the  CDP  implementation.  The  configuration  and  address  information  for  the  two 
cameras  provided  with  the  CDP  are  listed  in  Table  10-1. 


Table  10-1  -  SigniFire  IP  Camera  Details 


Camera  1 

Camera  2 

Tag  Number 

001485 

001484 

Camera  S/N 

XD0000000345 

XD0000000394 

MAC  address 

00-1B-5A-00-01-59 

00-1B-5A-00-01-8A 

Part  Number 

SigniFire  /P^vlo  1 

SigniFire  /P’^^0 1 

SigniFire  IP  S/N 

IP  00197 

IP  00214 

Software  Version 

1.842 

1.842 

Local  IP  address 

192.168.0.101 

192.168.0.102 

Camera  configuration  {e.g.  configuring  network  settings)  is  done  using  the  built-in  web  interface 
found  in  each  camera,  found  at  'http:  //192 . 168 . 0  .  lOl/admin'  for  CDP  Camera  #1. 
Administrative  privileges  are  required  for  configuration  changes.  The  user  name  and  passwords 
are  ‘admin’  and  ‘axonx’  respectively.  An  example  of  the  configuration  screen  for  CDP  Camera 
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#1  is  shown  in  Figure  10-2.  Please  refer  to  Sections  3.3  and  3.5  of  Reference  17  for  further 
details. 


ISigniF/Ae 


Operations 


C..O.IEF.A.  ST.^rjS 
CONTIC-VRE 
LnE  \'IDE0 

Relay  Control 
Snapshot 


.^MINISTRATION 


CONTIGLTE  • 

Report 

P.EST.ART 

Restore  ■■ 

UPC-R-ADE 

SCHEDILES 

Zones 


Done 


General  Settings 


Changes  to  the  network  and  camera  settings  require  the  camera  to  be  restarted  before  they  take  effect. 
Xettvork  Settings 


Domiin  Nime 


Camera  Settings 


Ctmera  Name 


SigniFire  IP 


©On  ©Off 


Q  Internet 


'A 


\  100%  - 


Figure  10-2  -  General  Settings  page  on  CDP  Camera  #l's  internal  Webserver. 

The  NVR  provided  as  part  of  the  system  coordinates  operation  and  data  logging  for  the 
SigniFire  IP  cameras.  The  NVR  has  two  network  interface  cards  (NICs).  The  first  NIC  (#1)  is 
configured  for  the  same  subnet  as  the  SigniFire  IP  cameras  (192.168.0.XXX)  and  is  used  for 
communication  with  the  cameras.  A  second  NIC  (#2)  is  provided  for  communication  with  an 
exterior  network,  but  it  is  not  currently  used  in  the  CDP  implementation.  The  NVR  NIC  1  IP 
address  is  192.168.0.10.  As  currently  configured,  all  CDP  network  devices  are  operating  on  the 
192.168.0.XXX  subnet  and  share  a  single  network  switch.  The  NVR  is  built  on  a  rack-mount  PC 
system  running  Windows  XP  Professional,  Service  Pack  3.  The  SigniFire  IP  server  software 
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installed  is  version  4. 1 .365 1 .29332.  The  main  user  interfaee,  SpyderGuard  IP,  is  eurrently 
version  4. 1.3678.3 1441  ^ 

10,2,  System  Startup 

Onee  installed  and  properly  configured,  the  SigniFire  system  is  designed  for  long  term  operation. 
If  the  NVR  and  SigniFire  server  software  have  been  properly  configured  since  the  last  power 
cycle,  system  startup  is  straightforward  with  no  required  configuration. 

Briefly,  to  start  up  the  system,  there  are  two  applications  that  need  to  be  started.  First  the 
SpyderGuard  IP  application  is  launched  using  the  previously  stored  configuration.  The 
configuration  file  (nrl  2  channels .  axf)  is  located  on  the  NVR  desktop.  Double-click  on  the 
configuration  file  to  launch  SpyderGuard  IP.  Second,  the  VSCS.Bridge  middleware  application 
is  launched  using  the  icon  on  the  NVR  desktop.  Once  both  systems  have  started  correctly,  the 
main  screen  of  each  application  will  resemble  those  shown  in  Figure  10-3  and  Figure  10-4. 


SpyderGuard-IP  -  C:\Documents  and  Settings\SigmFjre\DesktDp\NRL  2  Channels. axf 


Figure  10-3  -  SpyderGuard  IP,  Server  Tab,  with  Cameras  Loaded 


^  The  SigniFire  software  was  updated  by  axonX  Pike  during  the  shakedown  testing  of  the  CDP  on  ex-USS  Shadwell 
in  September,  2010.  Application  version  numbers  may  have  been  updated  at  that  time. 
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Figure  10-4  -  VSCS.Bridge,  Cluster  Tab 

10,2,1,  SpyderGuard  IP  Startup 

If  the  SigniFire  server  has  not  been  properly  configured  since  the  NVR  was  last  power  cycled, 
the  system  configuration  must  be  loaded  as  described  in  this  section.  Further  details  on  the 
SpyderGuard  IP  software  is  available  in  Reference  18.  Insure  that  the  provided  PoE  Ethernet 
switch  and  SigniFire  IP  network  cameras  are  plugged  in  and  powered.  If  necessary,  turn  on  the 
NVR  PC  and  allow  the  system  to  boot.  Eogin  as  the  user  “SigniFire”.  No  password  is  required. 
Allow  the  system  several  minutes  for  all  OS  and  SigniFire  services  to  completely  start  up.  Then 
launch  the  SpyderGuard  IP  application  by  double-clicking  on  the  configuration  file  stored  on  the 
system  desktop  (nrl  2  channels,  axf).  The  contents  of  this  configuration  file  are  given  in 
Reference  16. 

Once  the  application  has  launched  and  initialized,  the  SpyderGuard  IP  user  interface  should 
appear  as  shown  in  Figure  10-5  and  Figure  10-6.  While  the  configuration  file  has  been  loaded 
(as  can  be  seen  by  the  correct  camera  configuration  shown  in  Figure  10-6),  the  server  is  not 
properly  connected  to  the  cameras.  To  initiate  the  connections,  select  the  indicated  server 
(address  192.168.0.10)  on  the  Server  Tab  as  shown  in  Figure  10-7  and  select  the  “Add  Channel” 
button  in  the  middle  of  the  screen.  The  “Select  Available  Camera”  window  will  open,  as  shown 
in  Figure  10-8.  Select  both  cameras  as  shown  and  press  the  “OK”  button.  This  step  may  take 
several  minutes  to  properly  initialize.  The  system  is  properly  configured  when  the  number  of 
cameras  listed  in  the  left  side  of  the  status  bar  (lower  left  of  screen)  reads  “Cameras:  2”.  When 
complete,  the  Cameras  will  be  shown  in  the  Server  and  Browser  Tabs  as  shown  in  Figure  10-3 
and  Figure  10-9.  The  SigniFire  IP  system  is  now  properly  operating. 
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Figure  10-5  -  SpyderGuard  IP  on  Application  Start,  Server  Tab 


SpyderGuard-IP  -  C:\Documents  and  SettingsVSigmFjre\Desktop\NRL  2  Channels. axf 
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Figure  10-6  -  SpyderGuard  IP  on  Application  Start,  Browser  Tab 
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SpyderGuard-IP  -  C:\Documents  and  Settings\SigmFjre\Desktop\NRL  2  Channels. axf 

EBe  Edit  Tools  Help 

Seiveis  1  Biowset  j  Alarms  |  Archive  |  Titrieline  | 
j^AddServer  Remove  Server  jfDlsconnect  Properties 

1  Address 

Pott  ;  State  ServwTime  .Version  j  User  |  Secwty  |  | 

JBAddchannel..  Remove  channel 

1  Channel  |  State  |  Status  |  Name  |  Address  Version  |  Serial  |  I 

There  are  no  items  in  this  view 

1  Cameras:  0  Servers:  I  8/19/3010 10:45:42  AM  ^  ^  No  Relays  .| 

Figure  10-7  -  SpyderGuard  IP,  Server  Tab  with  Server  Selected 
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Figure  10-8  -  “Select  Available  Camera”  Window 
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Figure  10-9  -  SpyderGuard  IP,  Browser  Tab,  with  Camera  #1  Seleeted 

10,2,2,  VSCS,Bridge  Startup 

The  VSCS. Bridge  application  provides  the  connection  between  the  SigniFire  system  and  the 
CDP  VS  CnC  application.  To  launch  the  application,  double  click  on  the  VSCS.Bridge  icon  on 
the  system  desktop  after  the  SpyderGuard  IP  application  is  running  and  configured.  The 
application  will  open  and  after  a  brief  delay,  indicate  its  operation  state  as  shown  in  Figure  10-4 
by  the  presence  of  the  green  “OK”  box.  The  VSCS.Bridge  application  is  configured  via 
information  entered  in  a  series  of  tabs  shown  in  Figure  10-4,  Figure  10-10,  and  Figure  10-1 1 
rather  than  via  the  standard  .xml  files  used  by  the  rest  of  the  CDP  system.  The  corresponding 
.xml  configuration  file  loaded  by  the  VS  CnC  on  the  system  control  PC  must  match  the  settings 
given  in  the  VSCS.Bridge  application. 

On  the  “Clusters”  tab,  as  shown  in  Figure  10-4,  the  information  to  form  the  VSCS  string  ID 
(SID)  are  shown.  In  this  case,  the  IP  address  of  the  computer  running  the  VSCS.Bridge 
application  (192.168.0.10)  and  the  system  numerical  ID  (NID,  1)  are  entered.  Also  the  TCP  port 
used  by  the  SigniFire  IP  /  VSCS.Bridge  pair  is  entered  here  (5010).  This  TCP  port  is  not  to  be 
confused  with  the  UDP  port  used  for  VSCS  communication  that  is  specified  on  the 
“Destinations”  tab.  Changes  are  committed  by  pressing  the  [+]  button. 

On  the  “Destinations”  tab,  as  shown  in  Figure  10-10,  the  IP  address  and  receiving  UDP  port  for 
the  VS  CnC  application  is  listed.  In  this  case,  the  VS  CnC  is  running  on  the  system  control  PC 
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which  has  the  IP  address  192.168.0.1.  The  VS  CnC  is  configured  to  expect  communication 
from  the  SigniFire  System  on  UDP  port  50100.  The  UDP  port  (50100)  used  for  eommunication 
with  the  VS  CnC  should  not  be  confused  with  the  TCP  port  (5010)  used  for  VSCS. Bridge  to 
communicate  with  SigniFire  IP,  even  though  both  port  numbers  appear  on  the  “Destinations” 
Tab. 


Figure  10-10  -  VSCS.Bridge,  Destination  Tab. 

On  the  final  tab,  “Setup”,  the  UDP  port  for  incoming  commands  from  the  VS  CnC  and  the  NIC 
to  use  are  selected.  In  this  case,  they  are  “10200”  and  the  NIC  assigned  the  IP  address 
192.168.0.10,  as  shown.  The  SigniFire  system  is  now  properly  configured  to  run  and 
communicate  with  the  CDP’s  CnC  and  data  fusion  software.  All  configuration  values  are  stored 
and  will  be  correctly  populated  from  run  to  run. 


80 


User’s  Guide 


Figure  10-11  -  VSCS.Bridge,  Setup  Tab 

10,2,3,  SigniFire  IP  Camera  Zone  Configuration 

Due  to  the  sensitivity  of  the  SigniFire  IP  camera  event  detection  algorithms,  it  is  possible  to 
generate  false  alarms,  especially  smoke  events,  from  routine  events  occurring  in  the  space  such 
as  people  moving  around  in  the  field  of  view  of  the  camera.  As  general  practice,  exclusion  zones 
are  applied  very  liberally  in  SigniFire  installations  to  prevent  events  which  can  clearly  not  be 
smoke  or  fire  from  causing  false  alarms.  Inclusion  and  exclusion  zones  can  be  defined  for  each 
camera  using  either  the  camera’s  internal  web  server  or,  preferably  the  SpyderGuard  IP  GUI. 
Details  are  provided  in  the  supplied  References  17  (Section  3.5)  and  18  (Section  5.1).  An 
example  configuration  is  shown  in  Figure  10-12  using  the  SpyderGuard  IP  GUI  [19]. 

In  the  example,  the  entire  bottom  of  the  image  is  blocked  where  people  may  gather.  In  addition, 
zones  are  applied  to  cover  areas  where  light  effects  may  cause  the  alarms.  These  areas  can  be 
identified  after  letting  the  camera  run  for  some  time  and  reviewing  any  generated  false  alarms. 
The  zone  editor  has  a  built-in  feature  [Select..]  button  to  playback  the  recorded  alarms  to 
simplify  the  task  of  assigning  zones.  This  method  is  effective  because  zones  are  not  simply 
masking  the  image  as  was  the  case  in  earlier  generations  of  the  SigniFire  system.  The  camera 
applies  detection  algorithms  to  the  video  and  will  track  plumes  no  matter  how  zones  are  set.  The 
system  will  not  alarm  if  an  entire  plume  is  contained  inside  of  at  least  one  of  blocking  zone.  If 
detection  zones  are  being  used,  then  the  system  will  alarm  as  soon  as  the  plume  crosses  into  at 
least  one  of  the  detecting  zones.  Real  smoke  is  impossible  to  contain  and  it  always  breaks  out 
from  (to)  the  zone. 

The  configuration  of  zones  is  an  installation-specific  activity  that  depends  on  the  camera  field  of 
view,  so  this  process  should  be  followed  for  each  installed  camera. 
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Figure  10-12  -  SigniFire  Event  Detection  Zones 

10,3,  Video  Recording 

The  SigniFire  NVR  provides  the  facility  for  recording  the  video  that  is  collected  by  the 
SigniFire  IP  cameras.  The  NVR  is  recording  all  the  input  videos  from  all  channels  continuously 
in  a  circular  storage  buffer  along  with  any  event  information.  Old  video  and  events  are 
eventually  purged  as  they  reach  the  end  of  the  buffer.  Flow  long  video  is  stored  depends  on 
amount  of  disk  space  allocated  for  storage,  the  number  of  connected  cameras,  image  size,  etc. 
Please  refer  to  Reference  20  for  further  details. 
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The  operator  can  review  and  replay  logged  video  and  events  from  the  circular  storage  buffer 
using  the  Timeline  tab  in  the  SpyderGuard  IP  GUI.  Individual  events  and  arbitrary  sections  of 
time  can  be  selected  and  exported  from  the  buffer  for  permanent  archive  purposes.  Video  is 
stored  in  a  vendor-specific  format  (* .  axm)  using  a  proprietary  video  codec Please  refer  to 
Section  5.5,  “Reviewing  Video  Recordings  in  the  Timeline  Tab”  of  Reference  18  for  further 
details.  The  Movie  Player  utility  program  is  also  provided  on  the  NVR  to  convert  .axm  files  to 
the  standard  .avi  file  format. 

11.  Volume  Sensor  Quad-View  (VS  Quad)  Software 

Routine  operation  of  the  VS  Quad  software  for  the  CDP  is  straightforward  and  requires  no 
operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is  required 
and  presented  in  this  Section.  The  information  in  this  Section  is  excerpted  for  Reference  21. 

11.1,  VS  Quad  Software 

The  VS  Quad  application  is  designed  to  be  run  after  one  or  more  instances  of  the  LWVD 
application  has  been  started.  The  application  displays  the  video  streams  transferred  from  the 
LWVD  instances  with  predefined  labels,  as  directed  by  the  configuration  file.  No  processing  of 
the  video  streams  is  performed  by  the  VS  Quad  application.  The  VS  Quad  software  has  no  user 
interface  (GUI)  other  than  the  video  display,  but  is  useful  for  monitoring  the  LWVD  and  VID 
video  streams  in  real  time.  The  configuration  and  operation  of  the  software  is  briefly  described 
here. 

Upon  startup,  the  VS  Quad  application  is  displayed,  as  shown  in  Figure  11-1.  As  shown,  each 
video  camera  in  the  two  active  CDP  Sensor  Heads  is  monitored  by  an  instance  of  the  LWVD 
application,  for  a  total  of  two  instances  per  Sensor  Head  and  four  instances  total.  Each  instance 
of  the  LWVD  application  then  forwards  the  video  information  to  the  VS  Quad  application  via  a 
local  memory  buffer. 


^  The  video  codec  installer  is  available  on  the  NVR  in  the  archive  file,  axmclip.zip. 
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Figure  11-1  -  VS  Quad  Main  Screen 


11,1,1,  VS  Quad  Configuration 

All  configuration  of  the  VS  Quad  application  is  done  by  editing  the  contents  of  the  configuration 
file  (default .  ini).  The  configuration  file  associated  with  the  screen  shot  in  Figure  11-1  is 
given  in  File  Listing  11-1. 


File  Listing  1 1-1  -  Annotated  Version  of  the  VS_Quad  Configuration  File  (default .  ini) 


VS-QUAD  -  Canadian  Demonstrator  Prototype 
1 

LWVDmemf i 1 emap_l 
LWVD  1 
1 

LWVDmemf i 1 emap_2 
DVR  1 
1 

LWVDmemf i 1 emap_3 
LWVD  2 
1 

LWVDmemf i 1 emap_4 
DVR  2 
1 
1 

425 

320 

255  255  128 


Title  bar  text 

Upper  Left  Quadrant  Active  (l=Active,  0=lnactive) 
Memory  buffer  for  video  feed 
Quadrant  label 

Upper  Right  Quadrant  Active  (l=Active,  0=lnactive) 
Memory  buffer  for  video  feed 
Quadrant  label 

Lower  Left  Quadrant  Active  (l=Active,  0=lnactive) 
Memory  buffer  for  video  feed 
Quadrant  label 

Lower  Right  Quadrant  Active  (l=Active,  0=lnactive) 
Memory  buffer  for  video  feed 
Quadrant  label 

Pixel  number  of  top  edge  of  application 
Pixel  number  of  left  edge  of  application 
Width  of  application  in  pixels 
Height  of  application  in  pixels 
RGB  color  for  Quadrant  labels 


For  the  top  and  left  values  for  the  U1  screen,  the  example  above  in  File  Listing  11-1  indicate  top, 
left  coordinates  of  (1,1),  or  one  pixel  to  the  right  and  down  from  the  upper  left  corner  of  the 
screen.  As  a  note,  the  coordinates  (0,0)  refer  to  the  center  of  the  screen,  not  the  expected  top,  left 
comer  of  the  screen.  While  not  expected  to  be  a  routine  configuration  task,  the  DirectShow 
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graph  filter  needs  to  be  configured  one  time  per  computer  to  establish  the  link  between  the 
LWVD  and  VS  Quad  applications.  This  is  done  by  running  the  ‘runme.bat’  in  the  VS  Quad 
binary  directory.  The  path  is 

"C:\Volume  Sensor  Programs\VS_Quad\bin\runme.bat". 

11.1,2,  VS  Quad  Operation 

The  VS  Quad  application  can  be  launched  in  one  of  two  ways:  1)  launching  from  the  command 
line  (or  batch  file),  or  2)  by  double-clicking  on  the  application  icon  or  an  associated  shortcut.  An 
example  target  for  a  shortcut  to  launch  the  VS  Quad  application  is: 

"C:\Volume  Sensor  Programs\VS_Quad\bin\VS_Quad.exe" 

If  the  instance  is  properly  configured,  the  application  will  launch  and  run  as  shown  in  Figure 
11-1.  Operation  will  continue  until  the  application  is  closed  via  the  ‘X’  in  the  upper  right  comer 
of  the  application.  At  least  one  instance  of  the  LWVD  application  must  be  mnning  prior  to 
launching  the  VS  Quad  application.  If  the  LWVD  applications  are  stopped  while  the  VS  Quad 
application  is  mnning,  the  images  will  stop  at  the  last  received  frame.  No  other  notification  is 
provided. 

12.  Volume  Sensor  Command  and  Control  (VS  CnC)  Software 

Routine  operation  of  the  VS  CnC  software  for  the  CDP  is  straightforward  and  requires  no 
operator  intervention.  For  advanced  configuration  and  usage,  additional  information  is  required 
and  presented  in  this  Section. 

12.1.  VS  CnC  Software 

The  VS  CnC  application  is  designed  to  be  the  core  of  the  VS  system,  providing  communications 
services  between  all  of  the  VS  components,  gathering  data  from  the  sensor  analysis  programs, 
processing  the  data  through  the  data  fusion  algorithms,  and  transmitting  situational  awareness  to 
the  GUI  for  display.  The  configuration  and  operation  of  the  software  is  briefly  described  here. 

The  main  application  file  is  named  ‘cnc  debug .  exe’.  In  addition  to  this  executable  file,  two 
dynamic  link  libraries  (DLL)  are  required  for  normal  program  operations.  These  are 
‘vscomm_debug.dll’,  which  implements  the  VS  XML  communications  interface,  and 
‘libxml2  .dll’,  which  provides  a  standard  XML  programming  interface.  These  files  must  be 
located  in  the  same  directory  as  the  main  application  file. 

Upon  startup,  the  VS  CnC  application  main  window  is  displayed,  as  shown  in  Figure  12-1.  As 
configured  for  the  CDP,  command  messages  sent  from  the  GUI  are  counted  in  the  upper  text 
box.  Data  packets  received  from  the  sensor  components  are  counted  in  the  middle  text  box.  A 
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“heartbeat”  counter  is  displayed  in  the  lower  text  box  and  indicates  the  current  data  acquisition 
cycle  number  and  the  status  of  communications. 

A  series  of  buttons  and  checkboxes  provide  controls  for  advanced  users  and  for  debugging 
purposes.  The  Simulation  Interface  is  not  intended  for  use  in  the  CDP.  In  the  lower  right,  the 
button  labeled  ‘Done’  provides  a  convenient  way  to  close  and  exit  the  VS  CnC  program. 


Figure  12-1  -  VS  CnC  Software  Main  Screen  During  Demonstration 

12,2,  Operation 

The  VS  CnC  application  can  be  launched  in  one  of  two  ways:  1)  launching  from  the  command 
line  (or  batch  file),  or  2)  by  double-clicking  on  the  application  icon  or  an  associated  shortcut.  An 
example  target  for  a  shortcut  to  launch  the  VS  CnC  application  is: 

"C:\Volume  Sensor  Programs\VS_CnC\CnC_debug.exe" 


The  application  will  launch  and  run  as  shown  in  Figure  12-1 .  Operation  will  continue  until  the 
application  is  closed  via  the  ‘Done’  button  in  the  lower  right  corner  of  the  application,  or  the  ‘X’ 
in  the  upper  right  comer  of  the  application. 
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Normal  operation  do  not  require  the  operator  to  use  the  other  buttons  or  checkboxes  on  the 
VS  CnC  application.  Ail  operator  interaction  with  the  CDP  system  should  be  performed 
through  the  GUI.  However,  if  the  VS_GUI  application  becomes  unresponsive  (i.e.,  “freezes”)  or 
the  GUI  clock  stops  advancing  during  CDP  system  demonstration,  then  it  is  recommended  that 
the  ‘Stop  Clients’  button  on  the  VS  CnC  application  be  pressed  to  terminate  data  acquisition 
from  the  sensor  systems.  The  VS  GUI  and  VS  CnC  applications  may  then  be  closed  and 
restarted  for  continued  use.  Further  information  regarding  the  VS  GUI  application  can  be  found 
in  Section  13. 

12,3.  Configuration 

All  configuration  of  the  VS  CnC  application  is  done  by  editing  the  contents  of  the  configuration 
files  listed  in  Table  12-1.  These  files  are  located  in  the  same  directory  as  the  VS  CnC 
executable  and  tell  the  VS  CnC  application  which  IP  addresses  and  port  numbers  to  use  for 
itself,  the  GUI,  and  the  VID  application.  In  addition,  the  type  of  machine  vision  software  {e.g. 
vendor)  is  set.  Note  that  only  one  VID  system,  axonX  Pike’s  SigniFire,  is  supported  for  the 
CDP.  The  NRL  VSP  can  support  a  second  GUI  application,  however  one  GUI  is  available  for 
use  in  the  CDP. 


Table  12-1  -  VS  CnC  Configuration  Files 


CNC  Config.txt 

Sets  the  IP  address  of  the  VS  CnC  application  and  the  IP  address  of  the 
machine  vision  sensor  component. 

VSAlgConf ig . txt 

Sets  the  machine  vision  software  type  for  the  data  fusion  algorithms. 

GUIClientConf ig . txt 

Sets  the  IP  address  and  port  numbers  for  communications  with  the  GUI 
application. 

GuiSecondaryConf ig . txt 

Sets  the  IP  address  and  port  numbers  for  communications  with  a  secondary 
GUI  application.  (Not  used  in  the  CDP.) 

12,4,  VS  CnC  Communications  Interface  Configuration 

Configuration  of  the  XML  communications  interface  for  the  VS  CnC  application  is  done  by 
editing  the  contents  of  the  XML  system  definition  files  listed  in  Table  12-2.  These  files  define 
the  IP  addresses  and  port  numbers  of  all  VS  components  for  the  XML  communications  interface. 
They  also  define  the  structure  of  the  data  packets  to  be  received  by  the  VS  CnC  application 
during  normal  operations.  The  first  file  listed  in  Table  12-2,  ‘server .  xml ’,  is  located  in  the 
same  directory  as  the  VS_CnC  application  file.  The  other  files,  all  prefaced  with  ‘sysdef  ’,  are 
located  in  the  ‘conf  ig/  ’  subdirectory  and  must  match  exactly  the  system  definition  files  located 
with  the  sensor  applications. 
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Table  12-2  -  VS  CnC  XML  Communications  Files 


server . xml 

XML  definition  file  for  communications  with  the  VS  CnC 
application. 

conf ig/sysdef  SBVS  SSI  001. xml 

XML  definition  file  for  communications  with  the  SBVS 
application  processing  data  from  SS  #1. 

conf ig/sysdef  SBVS  SS2  001. xml 

XML  definition  file  for  communications  with  the  SBVS 
application  processing  data  from  SS  #2. 

conf ig/sysdef  LWVD  SSI  001. xml 

XML  definition  file  for  communications  with  the  LWVD 
application  processing  NIR  video  from  SS  #1. 

conf ig/sysdef  LWVD  SS2  001. xml 

XML  definition  file  for  communications  with  the  LWVD 
application  processing  NIR  video  from  SS  #2. 

config/sysdef  VSDVR  SSI  VIS  CPM.xml 

XML  definition  file  for  communications  with  the  DVR 
application  recording  VID  video  from  SS  #1. 

config/sysdef  VSDVR  SS2  VIS  CPM.xml 

XML  definition  file  for  communications  with  the  DVR 
application  recording  VID  video  from  SS  #2. 

config/sysdef  ACST  SSl-2.xml 

XML  definition  file  for  communications  with  the  ACST 
application  processing  audio  data  from  SS  #1  and  #2. 

config/sysdef  SF  2Cam.xml 

XML  definition  file  for  communications  with  the  SigniFire 
application  processing  video  from  IP  cameras  #I  and  #2. 

12.5.  Data  Logging 

The  VS  CnC  application  uses  several  log  files  to  record  all  data  received  from  the  sensor 
applications  and  all  data  fusion  processing  performed  with  that  data.  The  VS  CnC  data  files  are 
stored  in  the  same  directory  as  the  VS  CnC  executable, 

"C:\Volume  Sensor  Programs\VS_CnC\" 

These  log  files  are  listed  in  Table  12-3.  The  first  log  file  listed  in  the  table  is  created  whenever 
the  VS  CnC  application  is  started.  A  new  version  of  the  file  with  a  unique  filename  is  generated 
whenever  the  log  file  is  removed  from  the  directory  while  the  VS  CnC  application  is  running. 
The  unique  filename  is  generated  based  on  the  current  computer  date  and  time.  The  other  log 
files  listed  in  the  table  are  continuously  updated  if  they  already  exist,  or  are  created  anew  if  they 
don’t,  whenever  a  ‘Start’  command  is  received  from  the  VS_GUI  application.  Their  filenames 
are  static  and  do  not  change. 

Table  12-3  -  VS  CnC  Data  Logging  Files 


CNC  LogFile  (date)  (time) . txt 

Stores  all  data  packets  and  command  messages  received  or  sent  by  the 
CnC  application. 

DFAM  Log. txt 

Records  pertinent  messages  pertaining  to  the  operation  of  the  data 
fusion  algorithms  module. 

dataSSl  Log. txt 

Records  data  received  from  SS  #1  at  one  second  time  intervals. 

dataSS2  Log. txt 

Records  data  received  from  SS  #2  at  one  second  time  intervals. 

dataDFl  Log. txt 

Records  output  of  individual  data  fusion  algorithms  at  one  second 
time  intervals. 
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13.  Volume  Sensor  Graphical  User  Interface  (VS  GUI)  Software 

Routine  operation  of  the  VS  GUI  software  for  the  CDP  is  straightforward.  The  purpose  of  this 
section  is  to  provide  the  operator  with  more  detail  about  the  VS  GUI  application.  For  advanced 
configuration  and  usage,  additional  information  is  required  and  presented  in  this  Section. 

13.1.  VS_GUI  Software 

The  VS_GUI  application  is  designed  to  be  the  human  interface  to  the  VS  system,  providing  the 
operator  with  communications  services  to  the  VS  components  and  displaying  situational 
awareness  gathered  from  the  sensor  analysis  programs  and  the  data  fusion  algorithms.  The 
configuration  and  operation  of  the  software  are  briefly  described  here. 

The  main  application  file  is  ‘vsMonVl .  exe’.  In  addition  to  this  executable  file,  two  other  files 
are  required  for  normal  program  operations.  These  are  ‘Falcon  .dll’,  which  provided  a  video 
interface  that  is  not  available  in  the  CDP,  and  ‘vsMonVl  .pdb’,  which  was  used  for  runtime 
debugging.  The  layout  and  configuration  of  the  VS  GUI  application  is  contained  in  file 
‘Default .  txt’,  which  sets  the  IP  address  and  port  numbers  for  communications  with  the 
VS  CnC  software  and  also  defines  the  locations,  names,  and  data  content  of  the  sub  windows 
displayed  in  the  main  VS  GUI  application  window.  The  definition  file  is  intricate  and  complex 
and  should  not  be  altered  by  the  CDP  operator.  All  of  these  files  must  be  located  in  the  same 
directory  as  the  main  application  file.  These  files  are  located  in  the  location: 

"C:\Volume  Sensor  Programs \VS_GUI\" 

13.2.  Operation 

The  VS  GUI  application  can  be  launched  in  one  of  two  ways:  1)  launching  from  the  command 
line  (or  batch  file),  or  2)  by  double-clicking  on  the  application  icon  or  an  associated  shortcut.  An 
example  target  for  a  shortcut  to  launch  the  VS  GUI  application  is: 

"C:\Volume  Sensor  Programs\VS_GUI\VSMonVl.exe" 

The  application  will  launch  and  the  main  display  will  appear  similar  the  one  shown  in  Figure 
13-1 .  Operation  will  continue  until  the  application  is  closed  by  the  operator  via  the  ‘File’  menu 
‘Exit’  command,  or  the  ‘X’  in  the  upper  right  corner  of  the  application. 

The  GUI  communicates  with  the  VS  components  through  messages  sent  to  the  VS  CnC 
application.  In  order  to  establish  communications,  the  operator  needs  to  initialize  the  VS  system. 
This  is  accomplished  by  pressing  the  ‘Initialize’  button  in  the  Command  Toolbar,  as  shown  in 
Figure  13-2(a).  After  which,  the  Sensor  Subsystem  window  in  the  lower  right  of  the  VS_GUI 
main  window  should  appear  as  in  Figure  13-3(top).  The  sensor  systems  listed  in  this  window  are 
either  green  or  gray,  indicating  OK  or  HALT  status.  The  VS  AEG  system  represents  the  data 
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fusion  algorithms  and  is  in  the  OFF  state  at  initialization.  If  one  of  the  sensor  systems  shows  an 
orange  FAULT  state  or  a  gray  OFF  state,  then  additional  intervention  by  the  operator  is  required. 
Ensure  all  hardware,  eonneetions  and  software  systems  are  funetioning  properly  before 
attempting  initialization  again. 

Onee  the  initialization  proeedure  is  eomplete,  the  system  is  ready  for  demonstration.  Press  the 
‘Start’  button  shown  in  Figure  13-2  (a)  to  aetivate  the  system  and  eommenee  data  aequisition. 
Normal  operations  do  not  require  the  operator  to  use  the  other  buttons  or  eommand  menus  on  the 
VS_GUI  application.  The  Sensor  Subsystem  window  should  now  appear  as  shown  in  Figure 
13-3  (bottom)  with  all  systems  in  green  with  OK  status.  In  addition,  the  two  boxes  in  the  upper 
left  of  the  main  GUI  window  change  from  gray  to  green.  The  upper  box  indicates  whether  the 
system  is  started  or  stopped,  and  the  time  at  which  the  system  was  started  or  stopped.  The  lower 
box  indicates  the  current  system  status:  green  OK,  red  ALARM  (time),  or  gray  STOPPED.  Two 
operational  states  are  shown  in  Eigure  13-2  (a)  and  (b)  as  examples. 

If  the  GUI  becomes  unresponsive  (i.e.,  “freezes”)  or  the  GUI  time  clock  display  ceases  to 
advance  during  a  system  demonstration,  then  it  is  recommended  that  the  VS  GUI  application  be 
closed  and  the  ‘Stop  Clients’  button  on  the  VS  CnC  application  be  pressed  to  terminate  data 
acquisition  from  the  sensor  systems.  The  VS  GUI  and  VS  CnC  applications  may  then  be  closed 
and  restarted  for  continued  use. 

While  running,  the  GUI  provides  a  number  of  indicators  for  situational  awareness.  An  example 
is  the  active  ELAME  alarm  shown  in  Eigure  13-4.  In  general,  threat  levels  are  color  coded  as 
green  (OK),  yellow  (PRE  AEARM),  and  red  (ALARM).  Orange  is  used  to  indicate  a  EAULT 
state,  and  gray  an  OEE  or  HAET. 

To  cease  data  acquisition  and  stop  the  system,  press  the  ‘Stop’  button  shown  in  Eigure  13-2  (b). 
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Figure  13-1  -  VS_GU1  Software  Main  Sereen 
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Figure  13-2  -  VS_  GUI  Application  (a)  Initialization  and  Start  Buttons  (b)  Stop  Button 
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Figure  13-3  -  VS  GUI  Sensor  Subsystem  Window,  (top)  After 
Initialization,  (bottom)  Normal  Operations 
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Figure  13-4  -  VS_GUI  Software  Main  Sereen  With  Aetive  FLAME  Alarm 

13,3,  Situational  Awareness 

The  GUI  provides  a  number  of  indieators  for  situational  awareness.  These  are  found  on  the 
various  sub  windows  located  in  the  main  window  of  the  VS  GUl  application.  The  default  size 
and  layout  of  the  sub  windows  is  shown  in  Figure  13-1.  Most  of  the  sub  windows  can  be  resized 
and  re-positioned  at  the  convenience  of  the  system  operator.  For  the  remainder  of  this  section, 
the  ‘sub’  nomenclature  will  be  dropped  when  a  sub  window  is  referred  to. 

13,3,1,  The  LOG  Window 

The  LOG  window  is  located  in  the  upper  right  of  the  VS  GUl  application.  The  purpose  of  the 
LOG  window  is  to  display  all  messages  sent  from  and  received  by  the  VS  GUl  application. 

Two  examples  of  VS_CnC  /  VS  GUl  message  traffic,  as  shown  in  the  LOG  window,  are  shown 
in  Figure  13-5.  Typical  entries  for  system  commands  are  shown  in  Figure  13-5  (top).  These 
include  pressing  the  ‘Stop’  button,  which  sends  a  STOP  command  to  the  VS  CnC  and  generates 
an  ‘s>iooii,  GC_SYSSTOP,  All’  entry  in  the  LOG  window.  The  ‘s>’  indicates  the  message  was 
sent  from  the  VS  GUl  application,  the  ‘looii’  is  the  message  identification  number,  and  the 
‘gc_sysstop.  All’  test  string  is  the  System  Stop  message  for  distribution  to  all  sensor 
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components.  The  VS  CnC  confirms  receipt  of  the  message  in  the  subsequent  LOG  entry, 

‘r>i 0 oil,  ok’ .  Entries  for  pressing  the  ‘Initialization’  button  are  also  shown: 

‘r>iooii,  GC_SYSSTATUS,  All’.  In  this  case,  the  sensor  systems  respond  with  their  current 
system  status. 

After  a  ‘Start’  command  is  issued  by  the  GUI  operator,  data  packets  are  received  in  a  continuous 
stream  from  the  VS_CnC,  as  shown  in  Figure  13-5  (bottom).  Data  packets  from  sensor  systems, 
‘r>-i  ,  OK,  bor’,  alternate  with  packets  from  the  data  fusion  algorithms,  ‘r>-i  ,  ok,  boa’. 


MKl 


R>-1 ,0l^,B0A,BOSS,VSALG;in9[2.l68.0, 1,50001 00,OK,2C  >s 
System  Slopped  0 13:07:37 
S>1000ll,t3C  SYSSTOP>y.L 
R>lOOOn,OK, 

S>1 0001  2,GC_SYSSTaTUS^L 
System  reinitielized 

R>1 0001 2,OK,BOS  JaSSjSBVS:1:132.16aai,201 01 01 ,0 
S>1 0001 3,GC_SYSSTATUSm 
System  reinitialised 

R>1 0001 3,0K;BOS,8OSSXWVO:1:192.16a 0.1,40101 01  >  ^ 


R>-l,OK,EOR,BOS$;SevS:2;m.l6S.O.r2m  0202,OK,20l^ 
R  >  -1 ,0  OA,eOSS.VSALG:l  :1 32. 1 68.  ft!  ,50001 00,0  K,2C 
R>-1 , O<,EOR,BOSSiVA0!l:l92.l68.0, 1.40101 01  ,OK,20 
R>-1,OK,BOA,eOSS.VSALG;l:1^.l68l0.l, 5000100, OK, 2C 
R>-1,OK,BOR,EQSSIWVO:1;13(2.168.0.1.4010101,OK,20 
R>-1,OK,BOA,BOSS.VSALG:1:132,16a  0.1,5000tOO,OK,2C 
R>-1,0K,BORJOSSiWVO:l:mi6a0l1,4010101,0K,20 
R>-1,OK,EOA,EOSS.VSALG;1:132.16aO,l,5OO0100,OK,2C 
R>.1,OK,BOR,EOSS.SBVS:1:132.l6aO1,2Ol01O1,OK,201 
R>.1,OK,EOA,EOSS.VSALG;1:132.1GS.ai,5000100,OK,2C'^ 


Figure  13-5  -  The  VS_GUI  FOG  Window,  (top)  Command  Messages, 

(bottom)  Data  and  Algorithm  Packets 

13.3.2.  The  SENSOR  SUBSYSTEM  Window 

The  SENSOR  SUBSYSTEM  window  is  located  in  the  lower  right  of  the  VS  GUI  application’s 
main  screen.  The  purpose  of  the  SENSOR  SUBSYSTEM  window  is  to  display  the  status  of  the 
sensor  subsystems  and  the  data  fusion  algorithms  module.  Two  examples  the  sensor  subsystem 
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status,  as  reported  in  the  SENSOR  SUBSYSTEM  window,  are  shown  in  Eigure  13-3  and 
diseussed  in  the  Seetion  13.2.  The  Type/Name  entries  indieate  the  status  of  the  SigniFire 
maehine  vision  system  (CVlD/axonX  SE),  the  speetral  sensors  in  SS  #1  (SBVS/Speetral  1)  and 
SS  #2  (SBVS/Speetral  2),  the  NIR  video  stream  in  SS  #1  (LWVD/LWVD  1)  and  SS  #2 
(LWVD/LWVD  2),  the  acousties  system  (ACST/Aeoustie  1),  and  the  data  fusion  algorithms 
module  (VSALG/Summary).  The  possible  status  states  are  OEE  or  HALT  (gray),  OK  (green) 
and  EAULT  (orange). 

13.3.3.  The  SENSOR  ALARM  Windows 

The  SENSOR  ALARM  windows  are  loeated  in  the  lower  left  and  middle  of  the  VS  GUl 
applieation’s  main  sereen.  The  purpose  of  the  SENSOR  ALARM  windows  is  to  display  the 
current  threat  levels  and  the  recent  minimum  and  maximum  threat  levels  for  several  of  the  sensor 
alarm  algorithms.  These  threat  levels  do  not  latch,  meaning  no  values  or  conditions  presented  in 
these  windows  are  persistent. 

Two  threat  level  examples  for  the  SENSOR  ALARM  windows  are  shown  in  Eigure  13-6. 

Typical  entries  for  the  initialization  state  are  shown  in  Eigure  13-6  (top).  A  ELAME  event 
detected  on  the  machine  vision  (AxonX  SE),  SB  VS  (Spectral)  and  LWVD  (LWVD)  systems  is 
shown  in  Eigure  13-6  (bottom).  The  current  threat  level,  scaled  from  0.00  to  1.00,  is  indicated  by 
the  middle  row  of  numbers  and  is  color  coded  green  (OK),  yellow  (PRE  ALARM),  and  red 
(ALARM).  The  maximum  threat  level  in  the  last  30  seconds  is  indicated  by  the  top  row,  the 
minimum  by  the  bottom  row.  The  buttons  ‘AH’,  ‘  1  ’,  and  ‘2’,  at  the  top  of  the  SENSOR  ALARM 
windows  allow  the  operator  to  alter  what  information  is  displayed.  By  selecting  ‘1  ’,  only 
information  from  SS  #1  is  displayed  for  that  sensor  subsystem.  Select  ‘2’  for  SS  #2,  and  select 
‘All’  to  display  the  greater  threat  level  of  either  SS  #1  or  SS  #2.  The  default  state  is  ‘AH’. 
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Figure  13-6  -  The  VS  GUI  SENSOR  ALARM  Windows,  (top)  After  Initialization,  (bottom) 
With  Active  FLAME  Alarms 

13.3.4.  The  VS  ALGORITHMS  Window 

The  VS  ALGORITHMS  window  is  located  in  the  upper  middle  of  the  VS  GUI  application.  The 
purpose  of  the  VS  ALGORITHMS  window  is  to  display  the  current  threat  levels  and  the  recent 
minimum  and  maximum  threat  levels  for  data  fusion  algorithms.  These  threat  levels  do  latch  and 
can  only  be  reset  by  issuing  a  ‘Stop’  command  followed  by  an  ‘Initialization’  command. 

Two  data  fusion  algorithm  threat  level  examples  for  the  VS  ALGORITHMS  window  are  shown 
in  Figure  13-7.  Typical  entries  for  the  initialization  state  are  shown  in  Figure  13-7  (top).  A 
FLAME  event  detected  by  the  flaming  fire  data  fusion  algorithm  is  shown  in  Figure  13-7 
(bottom).  The  threat  levels  and  status  indicators  are  identical  to  those  used  in  the  SENSOR 
ALARM  windows. 
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Figure  13-7  -  The  VS  GUI  VS  ALGORITFIMS  Window,  (top)  After  Initialization, 
(bottom)  With  Active  Data  Fusion  FLAME  Alarm 

13.3.5.  The  FUSION  ALARM  TIMES  Window 

The  FUSION  ALARM  TIMES  window  is  located  in  the  upper  left  of  the  VS  GUI  application’s 
main  screen.  The  purpose  of  the  FUSION  ALARM  TIMES  window  is  to  display  the  alarm 
status  and  alarm  times  generated  by  the  data  fusion  algorithms  module  until  cleared  by  the 
operator.  These  alarms  do  latch  and  can  only  be  reset  by  the  ‘Clear’  button  next  to  the  alarm 
times.  Note  that  pressing  the  ‘Clear’  button  only  clears  the  display  and  does  not  reset  the  alarm 
latches  in  the  data  fusion  algorithms  module.  A  ‘Stop’  command  followed  by  a  ‘Start’  command 
is  required  to  reset  the  fusion  algorithms  in  the  VS_CnC  software. 

The  FUSION  ALARM  TIMES  window  corresponding  to  two  example  conditions  are  shown  in 
Figure  13-8.  Typical  entries  for  the  initialization  state  are  shown  in  Figure  13-8  (top).  A 
FLAME  event  detected  by  the  flaming  fire  data  fusion  algorithm  is  shown  in  Figure  13-8 
(bottom).  The  compartment  buttons  are  not  enabled  for  the  CDP. 
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Figure  13-8  -  The  VS  GUI  FUSION  ALARM  TIMES 
Window,  (top)  After  Initialization,  (bottom)  With  Active 
Data  Fusion  FLAME  Alarm 


13.3.6.  The  NUISANCE  DATA  TABLE  Window 

The  NUISANCE  DATA  TABLE  window  is  located  in  the  middle  of  the  VS  GUI  application’s 
main  screen.  The  purpose  of  the  NUISANCE  DATA  TABLE  window  is  to  display  the  current 
status  of  several  nuisance  scenarios  as  detected  by  the  sensor  systems.  These  alerts  do  not  latch. 


An  example  of  the  NUISANCE  DATA  TABLE  window  is  shown  in  Figure  13-9.  The  nuisance 
scenarios  shown  are  welding,  grinding,  torch  cutting,  engine  running,  and  people  working  in  the 
space.  Alert  levels  follow  the  same  scale  (0.00  -  1.00)  and  color  coding  as  with  alarm  levels. 
Note  that  when  the  welding,  grinding,  and  torch  cutting  (i.e.,  bright  nuisance)  scenarios  reach  red 
(1.0),  FEAME  and  SMOKE  alarms  at  the  fusion  level  are  blocked.  Blocking  of  these  alarms 
continues  until  60  seconds  after  bright  nuisance  alert  is  no  longer  observed. 
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Figure  13-9  -  The  VS  GUI  NUISANCE  DATA  TABLE  Window  after  Initialization 

14.  System  Component  Specifications 

This  section  briefly  enumerates  the  major  components  of  the  CDP,  their  configurations,  the 
vendors,  and  part  numbers. 

The  Eusion  Machine  computer; 

•  Hewlett-Packard  Z400  Workstation 

•  Intel  Xeon  W3565  Quad-core  CPU  @  3.2  GHz 

•  4  GB  of  RAM 

•  Windows  XP  Professional  x86  Service  Pack  3 

•  NVIDIA  Quadro  NVS  295  display  adapter 

•  IDS  EALCONquattro  express  4-channel  frame  grabber,  PCIe  version 

•  Lynx  LynxTWO-A  audio  card 

•  Lynx  audio  cable,  P/N;  CBL-L2 AUDIO 

•  500  GB  main  hard  drive 

•  1  TB  data  hard  drive 

The  SigniFire  computer: 

•  Custom  unit  provided  by  vendor,  axonX  Pike 

•  Intel  Core™2  Duo  E8400  CPU  @3.0  GHz 
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•  1  GB  of  RAM 

•  Windows  XP  Professional  x86  Service  Pack  3 

•  Integrated  Intel  graphics 

•  2  TB  main  hard  drive 

Phantom  Power  Supply 

•  Stewart  Audio,  48V  Phantom  Supply  Module,  P/N:  PM-4 

Network  Ethernet  Switch 

•  Linksys  8-Port  10/100  +  2-Port  Gigabit  Switch,  P/N:  SRW208P 

Fieldpoint  Unit 

•  Rugged  Intelligent  Ethernet  Controller  Interface,  NI  cEP-2000 

•  8-Channel  Analog  Voltage  and  Current  Input  Module  for  Compact  Eieldpoint, 

NI  cEP-AI-IIO 

•  8  Ch,  5  to  24  V  Sourcing  Counter  Compact  Eieldpoint  Module,  NI  cEP-CTR-502 

•  Integrated  Connector  Block  for  Wiring  to  Compact  Eieldpoint  I/O,  NI  cEP-CB-I,  2  each 

•  Phoenix  Contact  24  VDC  Power  Supply,  P/N:  Quint-PS-100-240AC/24DC/5 

•  Cosel  5  VDC  DC/DC  Converter,  P/N:  ZUS 1 02405 

CDP  sensor  head  accessories 

•  Power  supply,  SE  Power  (Ault  /  Condor)  P/N:  PW173KB2403F01,  3  each 

•  Optical  sensor  data  cable,  E-Com  P/N:  CSM9MF-50,  3  each 

•  Video  cable,  E-Com  P/N:  CC59A-50,  6  each 
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